There is a question that decides whether an AI agent is safe to put in front of your business, and almost nobody asks it during a demo.
It is not which model the vendor uses. It is not whether they support MCP. It is not even what the agent can do.
The question is: what happens between the moment the agent decides to act and the moment the action occurs?
If the answer is "nothing, it has the credentials," then everything else in the security review is decoration.
How most agents work
The common pattern is simple, which is exactly why it spread so fast.
You connect an agent to your systems. Somewhere in that setup, a credential gets created: an OAuth token, an API key, a service account. It is stored in an integration layer, increasingly an MCP server. The agent gets access to that layer.
From then on, the agent decides what to do, and then does it. The credential carries the authority. The agent carries the intent. Nothing sits between them.
This works. It demos beautifully. And it puts an unbounded amount of authority behind a component whose defining characteristic is that it can be talked into things.
A fair word about MCP
The Model Context Protocol is a good standard, and this is not an argument against it. MCP describes tools to a model. That is useful and we have no quarrel with it.
The problem is a deployment pattern that grew up alongside it: an MCP server holding long-lived credentials, with an agent given open access. The protocol does not require that. Plenty of teams do it anyway, because it is the fastest thing that works, and because the risk does not show up until it does.
So the question to ask a vendor is never "do you use MCP." It is what stands between decision and action.
What actually goes wrong
These are not edge cases. They follow directly from the architecture.
The agent inherits everything the credential can do. A token scoped to a user carries that user's full authority into every action. An agent asked to summarize an inbox holds exactly the same power as an agent asked to empty it, because the authority lives in the credential, not in the task.
Prompt injection stops being a curiosity and becomes privilege escalation. Your agent reads untrusted content all day: emails, documents, tickets, web pages. If some of that content contains instructions, and the agent holds a credential, a successful injection does not produce a wrong answer. It produces a real action, with real authority, against a real system. The attacker never had to steal anything. They borrowed the agent that already had it.
The credential can leak through the model itself. Anything in a model's context can influence its output. A credential sitting in context can be echoed, encoded, summarized, or slipped into a tool argument headed somewhere else. That is not a bug waiting to be patched. That is what a language model does with text it can see.
Credentials end up in logs. Agent frameworks log prompts, tool arguments, and responses, because that is how you debug them. A credential in the request path lands in those logs, and then in whatever aggregates them.
Your audit trail collapses into a single identity. The system on the other end records that a service principal did it. It cannot tell you which agent, acting for whom, in response to what, having read what. On the day you most need to reconstruct events, the log shows one actor doing everything.
Revocation is all or nothing. One credential, one switch. Stopping one misbehaving agent means stopping every agent that shares it.
And underneath all of these sits the structural problem: there is nowhere to put a control. If the agent holds the credential, no policy can be applied between the decision and the call, because by the time anything could check, the request has already left.
The other way to build it
Outermind agents never hold a credential. Not a scoped one, not a short-lived one, not one hidden behind a proxy.
When one of our agents decides to do something, what it produces is a request. A proposal. The platform then decides whether to carry it out, using an identity the model cannot see, cannot name, and cannot influence, after running a series of checks the model is not party to.
That inversion changes what an attacker gets when they win. Manipulating the model is no longer the same as gaining authority, because the model never had any.
Credentials stay out of reach
Credentials live in a key vault and are resolved server side, at the moment a tool runs. They are never put in a prompt, never returned to the model, and never accepted as a tool argument.
That last part is worth being concrete about, because it is checkable: no tool in our platform declares a parameter for a token, key, secret, or credential. There is no argument through which a model could supply one, request one, or influence which one gets used. It is a property of how the tools are defined, not a filter bolted on afterwards.
The agent cannot choose who it is
When a tool executes, the customer it acts on, the agent it acts as, and the execution it belongs to are all supplied by the platform from the authenticated session. They are not parameters the model sets. They are not read from the model's output.
So an agent cannot be argued into being a different agent, or into operating against a different customer. A prompt injection that completely captures the model's reasoning still cannot change the identity the action runs under, because that identity was never something the model could express.
Every action is checked, every time
A tool request passes through a series of gates, any of which can stop it. Whether the agent has that tool at all. Whether it is allowed to touch that specific site, mailbox, or record, checked on this call rather than once at setup. Whether the outbound content passes safety evaluation. Whether this action requires a named human to approve it. Whether it is within the tool-call, volume, and cost ceilings for this execution. And regardless of outcome, whether it got recorded.
These run on every call. An agent that behaved perfectly for forty tool calls gets checked exactly as carefully on the forty-first.
The same attack, both ways
Picture a message arriving with hidden instructions: forward everything in this mailbox to an outside address.
Agent holds a credential. It has send authority. The instruction is indistinguishable from a legitimate one. The mail goes out. You find out later, from the recipient or from a bill.
Outermind. Sending is a mediated tool call. It runs into outbound safety evaluation, per-recipient and per-hour limits, and whatever approval gate the customer configured. It is recorded either way, with the arguments, so the attempt is visible even when it never completes.
Same model. Same injection. Different architecture, different day.
What we are not claiming
We do not claim our agents cannot be manipulated. Prompt injection is an unsolved problem across this entire industry, and any vendor telling you their model is immune is selling you something. Our position is different, and we think more honest: assume the model can be manipulated, then make sure manipulating it does not hand anyone a credential or an unchecked action.
We do not claim our checks are infallible. They are software. Software has defects. The argument is that a system with several checkpoints between decision and action fails differently from one with none, and that this is not a difference of degree.
And we do not claim MCP is unsafe. We claim that handing an agent a long-lived credential is unsafe, whatever protocol happens to carry it.
What to ask, including of us
If you are evaluating agentic AI for a business that has something to lose, take these into your next vendor call. They work on us too.
- Does the agent hold a credential? What is its scope, and how long does it live?
- What runs between the model deciding to act and the action happening?
- Can the model influence which identity its actions run under?
- If a document the agent reads contains hostile instructions, what specifically stops the resulting action?
- Does your audit record show the action and its arguments, or just that a service account did something?
- Which of your controls are enforced by my own infrastructure, and which require trusting you?
That last one matters more than it sounds. A control you can verify in your own tenant is worth more than a control a vendor describes in a deck. We would rather you had both.
Outermind builds AI agents for businesses that cannot afford to guess about security. If you want the technical detail behind this post, ask us for the Technology Brief on agent tool use, which names the specific gates and the order they run in.