Consider two log entries, both technically complete:
SERVICE ACCOUNT — svc-crm-sync@corp.internal
2026-04-14T09:23:41Z | tool: GET /api/v2/contacts | status: 200
token: svc-crm-sync-prod | scope: contacts:read | caller: crm-sync-job-v3AGENT — agt-7f3a2b | session: sess-9d1c4e
2026-04-14T09:23:41Z | tool: get_contacts | status: 200
token: agt-7f3a2b | scope: contacts:read | model: gpt-4o | prompt_hash: a3f9c2...Same fields. Same timestamp format. Same scope annotation. One of these tells you what happened and why. The other tells you what happened, and then stops.
The service account log is legible because a human wrote the workflow that produced it. Someone, at some point, sat down and defined: when condition X, call endpoint Y, in sequence Z. The decision logic lives in code. The code is auditable. The sequence was knowable before it ran, which means the log entry is just confirmation — a receipt for a transaction whose terms were set in advance. If something goes wrong, you read the code, you read the log, and you reconstruct the chain. The "why" was authored before the "what" ever executed.
The agent log has a prompt hash. That hash tells you exactly what went into the model. It does not tell you what the model reasoned about that input, which tools it considered and rejected, or whether the same input tomorrow would produce the same tool call sequence. The decision-maker wasn't a workflow definition. It was a model reasoning over context at runtime. The log is a receipt for a transaction whose terms were set by inference, not by code.
The gap sits in the governance architecture, and no amount of log field standardization closes it. Most current conversations about agent security treat it as a formatting problem. The architecture says otherwise.
What MCP Reveals About the Gap
The Model Context Protocol is useful here not as a specification to master but as an architectural lens that makes the governance problem visible.
MCP operates at the semantics layer, not the transport layer. When you're thinking about API gateways or federation protocols, you're thinking about systems that route or mediate requests whose content is defined elsewhere. The gateway doesn't decide what the request says; it decides whether to pass it through. MCP is different. The MCP architecture splits the problem into two roles: an MCP client that interfaces with the model, and an MCP server that interfaces with the tools. The model, reasoning over context, decides which tools to invoke and constructs the calls. The MCP server executes them.
The model is not executing a predefined sequence. It is making a series of decisions — which tool, with what parameters, in what order — based on its current reasoning state. Those decisions are influenced by the prompt, by the conversation history, by the tool descriptions the MCP server has exposed, and by whatever the model's training has shaped it to do in situations that resemble this one. None of that reasoning is captured in the log entry. The log captures the output of the reasoning. The reasoning itself is, in the current state of most deployments, gone.
The client/server split creates a governance ambiguity that doesn't exist in service account architectures. The model decides what to call. The MCP server executes it. Authorization policy — what the agent is permitted to access — typically lives at the MCP server level, expressed as scopes on the token the agent presents. But the decision to invoke a particular tool, in a particular sequence, with particular parameters, lives in the model's reasoning. Who owns the policy governing that decision? Right now, in most deployments, the honest answer is: nobody has fully claimed it, because the tooling to govern it doesn't exist yet.
You might reach for the API gateway analogy here, because MCP servers do sit between the model and the tool endpoints, and that sounds like routing. Resist it. An API gateway enforces policy on requests whose content was defined by application code. An MCP server enforces policy on requests whose content was defined by model inference. The gateway's policy-enforcement surface is static — the set of possible requests is bounded by what the application can generate. The MCP server's policy-enforcement surface is dynamic — the set of possible requests is bounded by what the model can reason its way to, which is a much larger and less predictable set.
The Misconfiguration Analogy Doesn't Hold
The natural move, when you've been in identity long enough, is to frame this as an OAuth misconfiguration problem at scale. The agent has too-broad scopes. The token lifetime is too long. The resource server isn't validating correctly. Fix the scopes, tighten the lifetimes, enforce validation — and you've solved it.
Scope hygiene matters. It's also insufficient.
An OAuth misconfiguration is a static problem. A scope was granted that shouldn't have been, or a token wasn't validated correctly. You can find it, fix it, and the fix holds. The decision logic that produced the misconfiguration lives in code or configuration, and once you've corrected the code or configuration, the problem is corrected. The audit trail from before the fix tells you what happened. The audit trail from after the fix tells you the problem is gone.
With an agent operating through MCP, the scope boundaries still matter — they are necessary, and getting them wrong is still a serious problem. But scope boundaries don't reconstruct the decision chain. They tell you what the agent could have done within its authorized surface. They don't tell you what it chose to do, in what sequence, for what inferred reason, given the specific context it was operating in at that moment.
Imagine an agent with read access to your CRM, your calendar, and your email. All three scopes are correctly granted. The token is properly validated. The MCP server is enforcing scope correctly. Now the agent, given a particular prompt, reads a contact record, then reads a series of emails involving that contact, then reads calendar entries for the next two weeks, then drafts an email. Every individual tool call is authorized. The sequence, in aggregate, produces something that a human reviewer might find alarming — or might find completely routine. You cannot tell from the log which it is, because the log doesn't capture the reasoning that connected those calls into a sequence.
An OAuth misconfiguration gives you a wrong answer to a question the audit trail can ask. An agent's decision chain gives you a question the audit trail cannot currently ask at all.
Whether any production tooling today fully solves the decision-chain reconstruction problem is genuinely unsettled. Some vendors are building toward it — structured reasoning traces, tool-call provenance, prompt logging with linkage to downstream actions. None of it is standardized. None of it is complete. The field is early enough that confident claims about "solved" should be treated as marketing until you've seen the architecture.
The Question That Separates the Conversation
Most buyers thinking about agent security have thought about access control. They've asked: what can this agent reach? They've mapped the scopes, reviewed the token lifetimes, maybe stood up a privileged access management layer in front of the sensitive endpoints. That work is real and necessary.
Fewer have asked the second question: how do we reconstruct the decision chain after the fact? The access control question and the auditability question — why the agent accessed what it accessed, in what sequence, given what context — have different answers, and most governance frameworks are only equipped for the first one.
A seller who can draw that line clearly is doing something useful in the room. The product that fully solves the second problem doesn't exist yet. Naming the gap correctly is its own form of technical credibility. Buyers who are thinking carefully about agent governance already feel the gap. They may not have language for it yet.
The question that earns you the next conversation: "Who owns the authorization policies for what your agent can access, and how do you plan to reconstruct the decision chain after the fact?"
The first half, most buyers have an answer to. The second half, most buyers don't — and the ones who don't but know they should are exactly the ones worth talking to.