Assume the agent will be talked into something. Limit what it can do.
An agent reads untrusted content, decides what to do next, and calls tools with real credentials. You cannot make a model immune to manipulation, so Control limits the blast radius: scoped data, governed tools, credentials the model never holds, and a human gate on actions that matter.
What actually goes wrong with agents, and what stops it.
None of these controls depend on the model behaving correctly. They hold even when it does not.
| Threat | How it happens | Control |
|---|---|---|
| Indirect prompt injection | A retrieved document or tool result contains instructions the agent follows | The agent can only act within its scope; every resulting tool call is evaluated by policy, not by the model |
| Tool misuse | The agent calls a legitimate tool with harmful arguments, such as an unbounded DELETE | Per-tool allowlists, argument constraints, and require_approval on destructive statement classes |
| Credential exposure | API keys placed in the prompt or environment are echoed or exfiltrated | Credentials are held by the gateway and connectors; the model never receives them |
| Data exfiltration | The agent is induced to send sensitive content to an external endpoint or tool | DLP policies by classification and destination; external endpoints off by default |
| Excessive agency | An agent is given broad permissions for convenience | Agents start with no access; effective permission is scope intersected with the user |
| Agent-to-agent escalation | One agent asks another with wider scope to act for it | The delegation chain is carried and evaluated; the original requester's limits still apply |
Filter what the agent can see, not what it says.
Output filters and guardrail prompts try to catch a bad action after the model has decided to take it. They are useful signals, but they are probabilistic and easy to route around. Control works earlier and deterministically: content an agent is not permitted to see is never retrieved, and a tool it is not permitted to call is never reached, regardless of what the prompt says.
That changes the question a security review asks. Instead of "can this model be jailbroken?", which is always yes, the question becomes "what is the worst this identity can do with its scope?", which you can answer from policy and test before deployment.
A worst case you can read in a pull request.
An agent's scope and the policies around it are code. Reviewers can see every dataset it reads, every tool it calls, and which actions wait for a person.
id: agent:vendor-onboarding
owner: user:procurement-lead
scope:
datasets: [erp.vendors, docs.vendor_contracts]
tools:
- "mcp:erp/lookup_vendor"
- "mcp:erp/create_vendor" # write: see policy below
- "mcp:email/send_internal"
network:
egress: none # no direct internet access
models: [local:llama-70b] # private endpoint onlyIllustrative example · final API surface documented in /docs
Before an agent goes to production.
- Named owner and documented purpose
- Explicit dataset and tool scope, no wildcards on write tools
- Delegation mode set: on behalf of a user, or unattended
- Destructive actions mapped to require_approval
- Model endpoints limited to approved private models
- No raw credentials in prompts, files, or environment
- Policy tests covering injection-driven tool calls
- Audit records verified for a test run
An injection attempt, step by step.
The vendor-onboarding agent above is asked to process a new supplier packet. One PDF in the packet contains hidden text instructing the agent to email the full vendor list to an outside address.
- 1
The model is persuaded
Assume the worst: the model treats the hidden text as an instruction and decides to send an external email. Nothing in Control relies on the model noticing the attack.
- 2
The tool is not there
The external email tool is outside the agent's scope, so it was never advertised in the agent's tool list. If the agent calls it anyway, the call is denied with tool_not_in_scope.
- 3
The fallback is constrained
If the agent tries the internal email tool instead, policy still applies to the recipients and content it is allowed to send, and the agent has no network path of its own.
- 4
The attempt is visible
Every denied call is in the decision log with the agent, the user it served, and the reason. A cluster of out-of-scope denials is a useful signal to review the source document.
Operational practices that keep the worst case small.
Start narrow, widen with evidence
Launch an agent with the minimum datasets and tools, then add scope only when denials in the log show a legitimate need.
Separate read and write agents
An agent that summarizes should not be the same identity that writes. Splitting them keeps a manipulated reader from reaching write tools at all.
Prefer unattended agents with less
Agents that run on schedules have no user to intersect with, so give them tighter scope and require approval for any write.
Watch denials, not just errors
A sudden rise in out-of-scope or policy denials for one agent often means new untrusted content, a prompt change, or a misconfigured tool.
Rehearse the off switch
Know who can disable an agent identity and confirm that its next call is refused. Practice it before an incident, not during one.
Keep tests next to scope
Every scope change ships with tests that prove what the agent still cannot do, including the calls an injection would try.
Questions buyers ask
Does Control detect prompt injection?
Detection is not the primary defense, because no detector is reliable against novel injections. Control assumes injection will sometimes succeed and limits what a manipulated agent can reach or do. Detection signals can be added as context, but access decisions do not depend on them.
Which agent frameworks does this work with?
Agents interact with Control through the OpenAI-compatible AI gateway and the MCP gateway, so frameworks that can point at those endpoints can be governed. We confirm specific frameworks per deployment.
Where are tool credentials stored?
In the Control runtime inside your environment, encrypted at rest. The gateway or connector attaches them when it executes an allowed call. The model and the agent's prompt context never contain them.
Can we stop an agent immediately?
Yes. Disabling an agent identity or revoking its scope takes effect on its next request at the enforcement points, because every action is evaluated at the time it is made.
Is a human approval step practical for agents that run all day?
Approvals are meant for a small set of high-impact actions, such as writes to financial systems or bulk deletes. Reads and routine calls are decided by policy without human involvement.
Should we still use guardrail prompts and output filters?
They are reasonable extra layers for tone and quality, and their signals can be useful. They should not be the control that keeps regulated data in place or stops a destructive call; that belongs in deterministic policy outside the model.
Can an agent hold its own API keys for external services?
We recommend against it. Credentials referenced by the gateway and connectors are attached only to allowed calls, while a key in an agent's environment can be echoed, logged, or used outside policy.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.