When every system log says "authorized," but nobody can explain how authority traveled from the human to the tool — that is the delegation chain problem.
A CISO gets an incident report on Monday morning. A customer record was accessed, and a data export was initiated. The AI agent that made the call was authenticated, and the OAuth token was valid. The MCP server accepted the request. The downstream API returned data. Every system log says the same thing: authorized. Then the investigation starts.
The identity team can see a token, and the platform team can see an MCP tool call. The application team can see an API request. But nobody can answer the question that matters most: who actually authorized this action, and how did that authority travel from the human user to the final tool execution? This is the AI agent delegation chain problem. It is not only a logging problem. It is an execution-time access control problem.
How Access Actually Travels in an Agentic System
Railway described a real 2026 incident in which an AI agent found a long-lived token on a user's machine and used it to trigger a destructive, production-volume delete operation. The request was authenticated, and the API honored it as it would any CLI or CI pipeline call. Railway later noted that agents use platforms differently from humans: they move faster, take more turns, and the link between the original task and the executed action can drift.
In a typical SaaS workflow, a user clicks a button, and the application performs a known action. The access path is predictable. On the other hand, agentic systems are different. A human gives an instruction, and an AI agent interprets it. Then, it may plan several steps. It may call a sub-agent and choose an MCP tool. That tool may call a SaaS API, a database, or an internal service. Each step carries some form of delegated authority.
A complete chain usually has five decision points, running from the human user through the agent, the reasoning step, and the tool call, to the downstream API. At each boundary, two things happen. First, identity delegation: who is acting? Second, permission delegation: what is this actor allowed to do? These are not the same. A system may know that an agent acted "on behalf of" a user. But that does not prove the user intended the agent to export a customer record, delete a backup, or call a privileged internal API. This is where confused-deputy failures appear.
The agent becomes the deputy. It has valid access. But it uses that access in a context the original user never meant to authorize. The risk is no longer theoretical. The Cloud Security Alliance reported in March 2026 that 73% of organizations expect AI agents to become vital within the next year, while 68% cannot clearly distinguish between human and AI agent activity.
Authority passes through five boundaries before a tool executes. At each step, identity delegation and permission delegation are separate decisions — and both must be recorded.
What OAuth Logs Capture, and What They Miss
OAuth Token Exchange, defined in RFC 8693, goes further. It defines two semantics for delegated access. Impersonation, where the recipient acts as the original principal and is indistinguishable from them downstream. Delegation, where the issued JSON Web Token (JWT) carries an act claim that names the acting party. OAuth logs can show that a token was issued, refreshed, and used by a client. The act claim records who acted on whose behalf. None of these records which reasoning step produced the call, which MCP tool was invoked, which sub-agent selected the tool, which credential was derived for this hop, what scope was attenuated, or whether the action still matched the user's original intent. Downstream APIs validate audience and scope on the incoming token. They do not usually parse or persist the act chain into their own logs. The chain exists in the token, but it disappears once the token is consumed.
That distinction matters in a multi-agent authorization flow. A token can be valid while the action is wrong. An OAuth log may say, "authorized client used a valid token." An investigator needs a different answer: "This agent, acting under this user's original task, derived this scoped credential, called this tool, with these arguments, after this policy decision."
MCP Authorization Secures a Different Boundary
MCP adds another layer here. MCP clients must implement RFC 8707 Resource Indicators, so each access token is bound to a specific MCP server as its audience. MCP servers must validate that the token was issued for them. Proof Key for Code Exchange (PKCE) is mandatory. Token passthrough to upstream APIs is explicitly forbidden as a confused-deputy mitigation. A step-up authorization flow is also added for incremental-scope requests and Client ID Metadata Documents, as an alternative to Dynamic Client Registration. That is real authorization. The Railway-style failure is not due to the MCP authorization being missing. MCP authorization secures a different boundary.
The MCP specification does not standardize the cross-hop delegation record. There is no MUST or SHOULD for capturing the originating user, the parent agent that delegated, the reasoning step that produced this tool call, the credential derivation event for this hop, or a tamper-evident chain across MCP server boundaries. MCP's structured logging notification utility is scoped to a single server's local view. That is the gap a delegation chain record fills.
OAuth logs confirm that a token was valid. Investigators need to know whether the action was authorized for this agent, this task, this tool, and this moment.
What Breaks When the Chain Has No Record
A Scope That Was Never Meant to Travel This Far
The Railway incident clearly illustrates the practical issue. The company later said the token had account-scoped access, which was the maximum access possible, even though narrower token options existed. The register reported that the token had been created to add and remove custom domains, but it was scoped broadly enough to allow destructive operations.
That is the core of the problem. The credential was valid, but its blast radius was too large. A sender-constrained token bound to a private key would have made the discovered token harder to replay from a different process, since each request requires a proof signed with the bound key. This is what Demonstrating Proof of Possession (DPoP) specifies. DPoP adoption in operational platform APIs remains limited, and even where it is in place, it addresses only token replay. It does not narrow the scope, nor does it record who delegated what to whom.
For agent systems, a "valid credential" is not enough. The question is whether the credential was derived for this task, this tool, this resource, and this moment. CSA's April 2026 research found that only 8% of respondents said AI agents never exceed their intended permissions. That is why scope attenuation matters. Each hop should have less authority than the parent hop. The sub-agent should not inherit the full user session. The tool should not receive a broad standing credential. The downstream API should receive only what is needed for the exact operation.
Authority That Was Never Intended to Be Delegated
Another failure pattern is implicit authority. In 2025, the ForcedLeak vulnerability in Salesforce Agentforce demonstrated how hidden instructions in an external web-to-lead form could cause an agent to process both legitimate and malicious ones. The reported vulnerability carried a CVSS score of 9.4 and could enable CRM data exfiltration through indirect prompt injection. In 2026, ServiceNow disclosed CVE-2025-12420, an AI Platform flaw with a CVSS score of 9.3. Reports said it could allow unauthenticated user impersonation and arbitrary actions as the impersonated user.
These examples are not technically the same. But they point to the same security question: when an agent acts, whose authority is it using, and was that authority explicitly delegated for the final action? If the answer is spread across three logs, it is not an audit trail. It is a puzzle.
Investigations That Can't Close
After an incident, security teams need to answer simple questions. Who initiated the task? Which agent acted on whose behalf? Which credential was derived? Was the scope reduced at each hop? Was the record tamper-evident? Without these fields, investigators can prove that access happened. They cannot prove that the access was properly authorized.
This creates risk for incident response, compliance, and customer trust. It also weakens the root-cause analysis. Teams may rotate tokens or add prompts, but the real failure remains: the chain existed at runtime, but it was never written down.
What a Complete Delegation Chain Record Requires
A complete AI agent audit trail needs one record per hop, not one record per session. A session-level log is too broad. Agent behavior changes during execution. The agent may inspect data, reason, select a tool, call a sub-agent, and request a credential. Each transition is a decision point.
At minimum, each MCP delegation record should include: initiating principal, agent identity, parent agent ID, tool called, tool arguments, target resource, credential used, credential derivation method, scope at this hop, policy decision, timestamp, correlation ID, and hash of the prior record. The hash matters. If each record includes a hash of the previous record, the chain becomes tamper-evident. Changing one event breaks the chain after it.
The IETF draft is one of the clearest emerging proposals in this area. It defines a standard logging format for autonomous AI systems. It is still an individual Internet-Draft, not a ratified IETF standard, but it is important because it treats agent audit trails as a first-class security problem.
One record per hop, not one record per session. Each field answers a question an investigator will ask after an incident.
Credential Derivation as the Mechanism That Makes the Chain Auditable
Credential derivation is the mechanism that turns a log into proof. A standing service account says, "This agent had access." A derived credential says, "This access was minted for this exact call." That is a major difference.
A derived credential should be created at execution time. It should be scoped to one tool, one operation, one resource, and one short TTL. It should be bound to the requesting agent identity and the originating user context. This is where credential derivation becomes more than an idea. It becomes a control.
Modern infrastructure already uses related patterns for temporary credentials, time-bounded leases, and attested workload identities. The agent security pattern is similar, but it must be applied per tool call.
How AgntID Produces the Chain That Existing Logs Cannot
AgntID is designed to address this execution-time gap. Instead of asking teams to replace their IAM, MCP servers, or infrastructure stack, AgntID sits in the runtime path. Its MCP proxy intercepts agent-to-tool calls before they reach the MCP server. This matters because the proxy is present at the point where intent becomes action.
AgntID describes its model as MCP-first, customer-hosted runtime access control for AI agents, with scoped, ephemeral credentials created at execution time. It applies policy, evaluates the action, derives scoped credentials, executes the tool, and logs the full execution context for each tool call. That architecture provides audit trail fields that OAuth and HTTP logs often miss. AgntID can record the tool name, tool arguments, credential derivation event, and policy decision. This is important for CISOs and security engineers because the control happens before the tool executes. A SIEM can ingest logs. It cannot narrow a credential before a dangerous call. OAuth can issue a token. It cannot always understand the MCP tool arguments. An MCP server can process a request. It does not record the policy decision or the credential derived from it.
AgntID connects these layers at runtime. The result is an agent access control audit that answers the investigator's earlier questions: who acted, which tool was called with which arguments, which credential was derived, and which policy allowed the call.
This also changes prevention. The Railway-style failure depends on a broad credential being available to the agent. A per-call credential model reduces that blast radius because the tool receives only the access required for the approved operation.
AgntID gives detection tools the per-call context they need. The CSA found that more than half of organizations report between 1 and 100 unsanctioned AI agents, while only 15% said 76-100% of agents have defined ownership. In that environment, runtime records are not a nice-to-have. They are how security teams separate approved automation from shadow execution.
AgntID derives a new scoped credential for every tool call and records the complete chain — agent identity, parent agent, policy decision, credential scope — before execution reaches the MCP server.
FAQ
Doesn't OAuth Token Exchange (RFC 8693) already provide visibility into the delegation chain?
OAuth Token Exchange can help represent delegation between services, and RFC 8693 defines a standard way to exchange tokens. But OAuth logs usually do not capture the agent reasoning step, the MCP tool arguments, the downstream resource, or the policy decision behind each tool call.
If my SIEM ingests all agent logs, can't it reconstruct the chain after the fact?
A SIEM can correlate events, but only if the right fields exist. If the credential derivation event, parent agent ID, scope reduction, and policy decision were never recorded, the SIEM can only assemble fragments.
What is scope attenuation, and why does it need to be recorded at every hop?
Scope attenuation means that each delegated hop receives narrower permissions than the previous one. In agent systems, this prevents a sub-agent or tool from inheriting broad authority that was never needed for the specific task.
How does credential derivation per call differ from rotating service account credentials periodically?
Rotation changes a standing credential on a schedule. Per-call derivation creates a new, short-lived, narrowly scoped credential for one approved action, then lets it expire.