The conversation I keep having with teams shipping agents:

“We just need to stop prompt injection.”

I hear a version of this 3 times a week from developers in my network.

And honestly… I get it.

Prompt injection is real. A malicious user, document, email, or tool result can push the model toward a bad instruction.

But the more useful production question is not:

Can I trick the model?

It is:

What happens if I can?

The most dangerous agent is not the one you can manipulate.

It is the one you can manipulate and gave admin access.

---

7 Places Agent Security Breaks 🔐

Prompt injection asks whether the model can be redirected.

Production security asks whether the redirect has somewhere dangerous to go.

The execution layer is where that answer lives.

---

1️⃣ Over-Permissioned Tools 🔑

The first security review I want to see is not the system prompt.

It is the tool list.

Bad:

execute_sql(query)

Better:

get_customer(customer_id)

The broader the tool, the larger the blast radius.

An agent does not need a database-shaped hammer because the database happens to be behind the workflow.

It needs the smallest capability that completes the job.

TopiaX mascot choosing a narrow tool boundary

Look at 3 things:

• Surface area — how much of the system can this tool reach?
• Arguments — can the model choose an arbitrary table, tenant, recipient, or amount?
• Recovery — can the action be reversed if the model is wrong?

The model can propose. The application must own authority.

execute_sql(query) is not automatically unsafe in every product.

It is unsafe when the team has not made the decision explicit, constrained the target, or built a recovery path around it.

---

2️⃣ Effective Permissions Matter 🕵️

Friendly role names are not a permission review.

“Support agent” can sound harmless while its service token quietly carries write access across every customer record.

The permission that matters is the one produced after the system combines:

• User identity — who asked?
• Agent identity — which non-human actor is running?
• Service account — which credential reaches the API?
• Inherited grants — what did the upstream role bring along?
• Resource scope — which tenant, record, or environment is actually in range?

The role name is a hint.

The resolved permission set is the evidence.

---

3️⃣ Identity Must Travel With the Request 🪪

An agent acting “on behalf of” a user should not become a new anonymous superuser at the next service boundary.

Downstream services need enough context to enforce the end user’s permissions where possible — not only the agent’s service identity.

In MCP-style systems, that also means treating authorization as a real protocol boundary: validate the token for the intended resource, keep scopes narrow, and do not blindly pass an upstream token through to another service.

The request should carry an auditable chain:

User asks
→ Agent proposes
→ Application resolves actor + scope
→ Downstream service enforces
→ Receipt binds action to identity

TopiaX mascot tracing identity through layered access gates

Why does this matter?

Because identity without scope is theatre.

You need to know who asked, which agent acted, which credential was used, what resource was targeted, and whether the action was allowed for that exact combination.

---

4️⃣ Tool Descriptions Are Security-Sensitive 🧰

Agents select tools semantically.

That makes names, descriptions, schemas, annotations, and dynamically discovered capabilities part of your supply chain.

A tool called search and a tool called export_all_customers are not the same risk — even if both return JSON.

MCP’s tool model includes the name, description, input schema, output schema, and annotations. Those fields shape what the model sees and how a client reasons about a capability.

Treat them like code that influences execution.

The safe shape is:

Agent proposes
→ Resolve user permissions
→ Resolve agent permissions
→ Validate schema + target
→ Policy check
→ Approval if needed
→ Execute
→ Record receipt

Deterministic policy gate for agent tool calls

The tool description can help the model choose.

It should not be the final authority that lets the tool run.

Never trust free-form text in production systems.

Put the actual decision in code, policy, or a service that the model cannot rewrite with a confident paragraph.

---

5️⃣ Secrets Change Everything 🗝️

Secrets turn a model mistake into an access incident.

Check every place a credential can travel:

• Prompts — did a secret enter context at all?
• Logs — are request and response bodies being recorded?
• Traces — can an observability vendor see tool arguments?
• Tool outputs — does the API return tokens, headers, or internal URLs?
• Errors — does a stack trace reveal environment details?
• Memory — can a credential survive into a later run?

If a model can read a secret, assume there is eventually some path where it can leak.

The strongest fix is to keep the secret away from the model.

Let the application attach credentials after policy passes, inside the narrowest possible tool boundary.

That is the difference between:

Model sees credential → model decides where it goes

and:

Model requests operation → application checks scope → application attaches credential

The second path is less magical.

It is also much easier to audit.

---

6️⃣ Data Rules Must Survive RAG 📚

Retrieval is not authorization.

Do not retrieve everything and ask the model not to reveal sensitive content.

That is a prompt-shaped access control.

Prefer:

Identity
→ Permission filter
→ Allowed dataset
→ Retrieval
→ Model

Permission-filtered retrieval path

The filter belongs before retrieval whenever the data system can enforce it.

That keeps disallowed records out of the context window, out of traces, and out of the model’s possible answer space.

Ask 3 questions:

• Tenant — which customer or workspace owns this record?
• Purpose — is this retrieval allowed for the current task?
• Sensitivity — does the combined result reveal more than any single document?

RAG can improve relevance.

It does not grant permission.

---

7️⃣ Rollback Is a Security Feature ↩️

When a high-impact workflow goes wrong, “turn off the model” is not a complete response.

You need a deterministic stop path:

Pause workers
→ Revoke capabilities
→ Identify affected records
→ Verify external state
→ Roll back or reconcile
→ Resume or escalate

TopiaX mascot tracing a controlled rollback loop

Timeouts deserve special attention.

A timeout is not proof that the action failed. It may mean the side effect completed and the receipt disappeared.

TIMEOUT
→ UNKNOWN
→ VERIFY
→ RECONCILE
→ RESUME OR ESCALATE

Blind retry is how a security event becomes 2 security events.

Your rollback plan should name the owner, the kill switch, the affected systems, and the evidence needed before the workflow resumes.

---

The 48-Hour Security Review Shape 🧾

You do not need a 6-month security programme to find the first dangerous permission boundary.

You need 48 focused hours around one real workflow, one owner, and one dated decision.

48-hour agent security review map

This is not a promise that every risk disappears in 48 hours.

It is a way to stop arguing about “AI security” as an abstract category and start proving what one workflow can and cannot do.

---

The Real Bottom Line ⚡

A secure agent does not need to be impossible to manipulate.

It needs to remain bounded when manipulation eventually happens.

Model output       = untrusted proposal
Application policy = authority
Tools              = minimum capability
Permissions        = resolved at runtime
Receipts           = proof of what happened
Rollback           = permission to operate again

Prompt injection plus read-only search is annoying.

Prompt injection plus admin tools is an incident.

The difference is not a better system prompt.

It is the execution layer.

---

Your Turn 👇

What is the most dangerous permission your agent can reach today?

Raw SQL?

Customer data?

Outbound email?

Production deploys?

Drop it below 👇

Let's compare the blast radii 😄