The path nobody authorised

The confused deputy is older than cloud computing, OAuth and language models. Norm Hardy’s canonical example concerned a compiler with two distinct powers. It could append usage statistics to a protected system file, and it could write optional debugging output to a filename supplied by a user. A malicious user supplied the protected statistics filename as the debugging destination. The compiler then exercised its own write authority on the user’s designation and damaged the file. The operating system saw an authorised compiler writing a file it was allowed to write. It did not preserve the reason for which each authority existed.[1]

The important detail is not that filenames are dangerous. It is that two references with different authority lineages looked identical at the moment of use. One reference meant “the compiler’s private statistics object”. The other meant “a destination the caller is entitled to choose”. When the deputy resolved both as ambient filenames, it lost the distinction between its own authority and its caller’s authority.

Why the modern deputy looks like an insider

A workload identity is a legitimate identity for software such as an application, service, script or container. Current enterprise guidance explicitly distinguishes these machine or non-human identities from human identities, and notes that they often hold several credentials and have weak lifecycle controls.[18] NIST’s zero-trust model likewise includes non-person entities and requires per-request, least-privilege decisions close to protected resources.[9]

That vocabulary is useful, but “non-human identity” is not yet the full risk. A nightly backup job has a machine identity. So does a payment service. Neither is automatically an insider in the sense developed here. A non-human insider is a trusted workload whose normal placement gives it enough read, transform and effect authority to create a prohibited path from inside the boundary. The term describes architecture, not intention. The workload may be buggy, manipulated, compromised or simply given an ambiguous task.

Agentic systems intensify this old pattern because they choose tools from natural-language context. Retrieved text can alter their proposed behaviour through indirect prompt injection, including which APIs they call.[15] The same runtime may read internal documents, query databases, write tickets, send messages and invoke third-party services. Each integration is justified by some workflow. The dangerous authority often appears only when those integrations are composed.

Privilege is a vector, not a height

Security reviews often compress privilege into a scalar: low, medium or high. That is useful for inventory, but it hides the geometry that matters here. Consider a vendor-onboarding assistant with permission to read supplier questionnaires, consult internal risk rules, create procurement tickets, draft email and upload approved documents to a supplier portal. None of those permissions is obviously excessive. Remove any one of them and a legitimate workflow may fail. Yet the set creates several possible routes from an internal source to an external sink.

The relevant privilege is therefore a vector. Its dimensions include which source may be read, which transformation may be applied, which sink may receive the result, whose authority is represented, which purpose is active, how long the grant lasts and how much information may move. Two assistants can possess the same list of API scopes while having very different effective authority. One routes every upload through a policy gate that knows the source labels and approval digest. The other exposes the portal credential directly to the model runtime. Their IAM screenshots look similar. Their reachable information paths do not.

flowchart LR
  A["At 09,17, every permission worked"] --> B["The path nobody authorised"]
  B --> C["Two permissions that do not add up"]
  C --> D["Put authority outside the model"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#007D68,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Two permissions that do not add up

Most identity and access management systems answer a local question: may principal P perform operation O on resource R under current conditions? That question is necessary. It is not sufficient for a system that transforms and relays information. Access control can prevent an unauthorised read, yet say nothing about where information goes after an authorised read. It can prevent an unauthorised write, yet say nothing about which sources influenced an authorised write.

Dorothy Denning’s lattice model made this distinction formal: secure information flow concerns paths implied by a collection of rights, not only immediate access to objects.[4] Later information-flow work treated labels as a type-like discipline that follows data through computations, including explicit and implicit flows.[5][6] The practical lesson for agents is direct. Authority says what a component may do; flow policy says what information may be carried by what it does.

The authority-flow path envelope

The proposed synthesis is an authority-flow path envelope. It combines four things that are usually evaluated separately: a capability grant, a delegation lineage, a data-flow constraint and a cumulative budget. Call the proposed sequence of steps π. For each step i, the system evaluates four predicates:

grantᵢ asks whether the current actor has a narrow capability for the action and resource. delegationᵢ asks whether subject, actor, purpose, audience and expiry still match the initiating authority. flowᵢ asks whether the join of all labels carried so far may enter the next sink. budgetᵢ asks whether the path remains within record, value, rate or irreversibility limits.

This is not a claim that all policies form one elegant lattice. Enterprise rules often include incomparable categories, legal purposes, tenant boundaries and one-off declassification decisions. The useful point is narrower: the path is valid only where action authority and information-flow authority overlap for the same delegation. An ACL permit cannot substitute for a flow permit, and a flow permit cannot create an action capability.

The graph state must travel with the data

A local authoriser receives a request and asks what is true now. A path authoriser must also know what became true earlier. The smallest useful carried state is a tuple containing the represented subject, active purpose, source labels, provenance references, cumulative volume, expiry, approval digest and the transformations already performed. Every read expands that state. A join takes the union of relevant categories. A write checks the resulting state against the sink. A declassification replaces a label only when a separately authorised transformation produces a verifiable receipt.

This state cannot be reconstructed reliably from the final prose. A harmless-looking sentence may be derived from a restricted database, an approved aggregate view, a public web page or a hallucination. The string does not reveal which route produced it. Nor can the system ask the model to remember the route faithfully, because the model is the component whose proposal is being constrained. The enforcement metadata must travel beside the content in a channel the proposer cannot silently rewrite.

Forking makes this requirement visible. Suppose a workflow reads ninety records against a budget of one hundred, then splits into two parallel branches. If each branch copies the local counter of ninety and is allowed ten further reads, the combined workflow reaches one hundred and ten while both branches appear compliant. The budget therefore belongs to a shared workflow lineage, not to an individual process. The same applies to one-time approval and declassification receipts. A fork may inherit the obligation to consult the common ledger, but it must not duplicate the authority as if each copy were the only continuation.

A small numerical example

Use four confidentiality ranks only for the toy calculation: public = 0, internal = 1, confidential = 2 and restricted = 3. A computation’s carried rank is the maximum rank of its inputs. The agent reads an internal instruction (1) and a confidential ledger row (2), so the joined rank is max(1, 2) = 2. An external webhook with clearance 0 cannot receive it because 2 ≤ 0 is false. An internal case ticket with clearance 2 can receive it because 2 ≤ 2 is true.

The assumption is that rank order captures the relevant policy. Remove that assumption and a single number fails. “Client A confidential” and “Client B confidential” may be equal in rank but forbidden to mix. Purpose restrictions may also be orthogonal to confidentiality. A practical label therefore needs categories and obligations, for example {rank:2, tenant:A, purpose:resolve-break}, not a scalar alone.

Put authority outside the model

The central engineering move is simple to state: the model proposes; a smaller deterministic authority kernel disposes. The model may interpret language, generate options and construct a typed plan. It does not hold general-purpose secrets, mint its own delegation, lower data labels or directly open network connections. A proposal is not an effect.

This follows long-standing security principles. Saltzer and Schroeder argued for complete mediation, least privilege and separation of privilege.[3] Capability systems make authority explicit and delegable rather than ambient; their advantage against confused deputies depends on preserving that discipline through the design.[7] Modern zero-trust guidance places policy decision and enforcement points near resources, with explicit user, application and service identities.[10]

The agent architecture needs to add what ordinary service authorisation often omits: the lineage and information context of the whole task. OAuth token exchange can represent a current actor and a nested delegation history through the act claim.[11] Workload identity systems such as SPIFFE can cryptographically identify a service.[13] These are valuable building blocks. Neither, by itself, proves that data from BR-44 may be posted to a supplier. Identity, delegation history and flow policy remain separate facts.

The smallest enforceable architecture

A minimal implementation has seven boundaries. First, the user or upstream service issues a typed intent containing subject, purpose and expiry. Second, a capability broker mints short-lived grants for specific resources, verbs, audiences and budgets. Third, read proxies attach labels and provenance to returned data. Fourth, the model produces a plan whose arguments are typed objects, not raw shell commands or unrestricted URLs. Fifth, the authority kernel evaluates the current path envelope before each effect. Sixth, tool proxies enforce the decision without exposing credentials to the model. Seventh, effect receipts and independent readback establish what happened.

The system should carry these as separate fields. Do not put them in a vague “memory” blob. The initiating human is the subject. The agent workload is the actor. The business reason is the purpose. The current protected values are world state. The model output is a proposal. The capability is authority. The API request is a typed action. The log and downstream confirmation are receipts and verified outcome.

Mediation begins at the read boundary

An egress gateway is necessary, but it is too late to invent provenance. By the time a proposed action reaches the gateway, the model may have summarised several sources, copied values into tool arguments, stored intermediate text or combined data from different tenants. If the reads were unlabelled, the gateway sees an output without a trustworthy account of what influenced it. It can classify the text heuristically, but that is a new model judgement, not evidence of origin.

A read proxy should therefore attach mandatory, non-model-authored metadata at acquisition. The content may enter the model context, while a parallel enforcement envelope records the source object, tenant, subject entitlement, purpose restriction, confidentiality categories, acquisition time and integrity reference. Derived objects inherit the join of their inputs unless an authorised transformation says otherwise. Missing metadata is not interpreted as public. It is an incomplete path and should fail closed for consequential sinks.

This design narrows what the model must be trusted to do. It may choose a useful source and propose a destination. It need not make the final claim that its own output is safe. That claim belongs to the authority kernel, using evidence collected at boundaries the model cannot bypass.

Capabilities must name the circumstance

A capability such as “can send email” is too broad. A usable grant resembles a transaction contract: actor recon-agent; subject Maya; purpose resolve-break; action append-case-note; resource prefix ops-ticket/BR-44; audience internal-operations; accepted labels up to client-confidential; maximum fifty records; expiry in ten minutes; one successful use; revocable before effect.

Cloud platforms already use contextual bindings to address parts of the deputy problem. AWS recommends external IDs for cross-account delegation and source account or source resource conditions when a service principal acts on behalf of another resource.[14] The principle is broader than any provider: the deputy must carry an unforgeable statement of the circumstance in which its authority is valid. A workload name alone does not carry that circumstance.

Declassification is an authority, not a string operation

Useful systems sometimes need to lower a label. A fraud team may publish an aggregate after removing identifiers. A support agent may share one field with a supplier. The mistake is to treat summarisation, redaction or model rewriting as automatic declassification. A model can omit sensitive text in one run and reproduce it in another. It can also reveal information through counts, rare categories or combinations.

Declassification should therefore be a separate typed action with its own authority, transformation, test and receipt. The policy might permit client-confidential → internal-aggregate only through a fixed aggregation function over at least twenty cases, with forbidden columns removed and an output test. The resulting lower label is attached by the declassification service, not asserted by the model that wants to send it.

Executable lab: PathGate

PathGate is a deliberately small browser-based checker. It evaluates synthetic paths against explicit grants, delegation fields, data-label clearances and a cumulative record budget. The lab exposes a fact that prose can hide: a path can fail even when every requested verb appears in the actor’s grant set.

The encoded assumptions are explicit. Labels are ordered by rank, tenant categories must match, every step must preserve subject and purpose, each sink declares a maximum rank, and reads accumulate against one workflow budget. A positive result permits only the encoded path under those assumptions. A negative result identifies the first failed invariant. It does not prove attacker intent. The checker cannot validate whether labels are correct, detect covert channels, secure a bypassable proxy or establish that the model is aligned.

function evaluatePath(spec) {
  const rank = { public: 0, internal: 1, confidential: 2, restricted: 3 };
  const failures = [];
  let carried = { rank: rank.public, tenant: null };
  let records = 0;

  for (const [index, step] of spec.steps.entries()) {
    const grant = spec.grants.find(g =>
      g.actor === spec.actor &&
      g.action === step.action &&
      step.resource.startsWith(g.resourcePrefix) &&
      g.subject === spec.delegation.subject &&
      g.purpose === spec.delegation.purpose &&
      g.audiences.includes(step.audience)
    );

    if (step.action === "read") {
      carried.rank = Math.max(carried.rank, rank[step.label.rank]);
      carried.tenant = carried.tenant || step.label.tenant;
      records += step.records || 0;
    }

    const stepFailures = [];
    if (!grant) stepFailures.push("No matching capability grant");
    if (step.subject !== spec.delegation.subject ||
        step.purpose !== spec.delegation.purpose) {
      stepFailures.push("Delegation lineage changed");
    }
    if (step.sinkMaxRank !== undefined && carried.rank > step.sinkMaxRank) {
      stepFailures.push("Information label exceeds sink clearance");
    }
    if (step.tenant && carried.tenant && step.tenant !== carried.tenant) {
      stepFailures.push("Tenant boundary changed");
    }
    if (records > spec.delegation.maxRecords) {
      stepFailures.push("Cumulative record budget exceeded");
    }
    if (stepFailures.length) failures.push({ step: index + 1, stepFailures });
  }

  return { allowed: failures.length === 0, failures, carried, records };
}

stateDiagram-v2
  [*] --> Claim
  state "Why the modern deputy looks<br/>like an insider" as Claim
  state "Privilege is a vector, not a<br/>height" as Test
  state "The badge swap" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

Break the system before attackers do

A policy diagram is not evidence that the boundary holds. The relevant evaluation is failure injection against a configured system. The model should be treated as potentially adversarial, not because every model is malicious, but because this test removes dependence on prompt obedience. If the system remains safe while the proposer actively searches for bypasses, the control is placed somewhere meaningful.

Current MCP security guidance gives a concrete contemporary example: a proxy server using one static OAuth client identity for several downstream clients can become a confused deputy unless consent is bound per client and redirect handling is strict.[17] OAuth security guidance similarly emphasises exact bindings, sender constraints and narrow token use.[12] Protocol compliance helps, but the end-to-end application still decides which user, purpose, data and effect belong together.

A failure-injection set that earns confidence

The operating metrics should not be only “attack blocked” and “task completed”. Measure false denials, additional latency, number of grants minted, label coverage, unmediated egress attempts, stale-token rejections, human-review burden and recovery after partial execution. A control that stops all work is safe only in a trivial sense. A control that allows work but forces staff to approve opaque prompts may simply move the deputy problem into the human interface.

Unknown outcomes are security states

Tool execution introduces a further path problem: the caller may not know whether an effect occurred. An external API can accept a message and then time out before returning its receipt. If the agent retries, the same confidential payload may be disclosed twice, the cumulative budget may be exceeded or two conflicting records may be created. Treating the timeout as simple failure loses a fact that matters to both authority and flow.

The kernel should reserve budget and bind an idempotency key before releasing an effect. A confirmed receipt commits the reservation. A definitive rejection releases it. A timeout moves the path into an unknown-outcome state. From there, a readback or provider-side idempotency lookup must establish what happened before another equivalent effect is permitted. The model may suggest a recovery plan, but it cannot declare the outcome absent merely because no response reached the conversation.

This is why recoverability belongs inside the security argument rather than in a separate operations checklist. A path remains governed only while its authority, evidence and effects can be reconciled after interruption. Otherwise uncertainty becomes a route around the very limits the policy was meant to enforce.

There is also a legitimate alternative explanation for some incidents. What appears to be a confused deputy may be a direct authorisation bug: the caller really was granted the wrong resource. Or the model may fabricate data rather than leak it. Or a third-party tool may retain data after a permitted transfer. The path ledger helps distinguish these cases because it records which source values influenced which proposed and executed effects. It does not decide the classification automatically.

What a human approval must actually show

Human confirmation is often added as a final safety layer. It works only when the interface presents the decision-relevant path. “Allow the agent to continue?” is not enough. A useful confirmation states: Maya delegated the reconciliation agent to resolve BR-44; the plan will read forty-two confidential records from Client A; it will append one note to the internal operations ticket; no external destination is involved; the capability expires after one use.

For an external or irreversible action, the interface should expose the destination, data categories, cumulative volume, declassification receipt and failure semantics. Approval must bind to an action digest and a visible path, not to a conversational impression. Otherwise the human becomes another confused deputy, using organisational authority on a proposal whose origin and consequences remain hidden.

sequenceDiagram
  participant Q as Question
  participant M as Mechanism
  participant E as Evidence
  participant D as Decision
  Q->>M: At 09,17, every permission worked
  M->>E: Why the modern deputy looks like an insider
  E-->>M: compare rival explanations
  E->>D: Authorise the route before its steps can compose
  D-->>Q: revise scope or act

Authorise the route before its steps can compose

Do not approve an agent because its service account has “least privilege” in the ordinary sense. That phrase is too local for a system that reads, transforms and acts across several trust domains. The release question is now: Can any path available to this configured system carry this class of information to that class of effect under a delegation that never authorised the journey?

Answer it on the configured system, not the model card. Enumerate the high-value sources and sinks. Remove ambient credentials from the model runtime. Mint capabilities for one subject, purpose, audience and time window. Attach provenance and labels at read boundaries. Re-evaluate the accumulated path before every effect. Reserve budgets before release. Record effect receipts and verify the outcome through a different path. Then inject hostile instructions, forks, stale grants, cross-tenant resources and unknown outcomes.

• Reject any architecture in which retrieved text can directly exercise a general-purpose credential.
• Reject any grant that names only an actor and verb while omitting subject, purpose, resource, audience and expiry.
• Reject any external effect whose policy engine cannot identify the source labels and cumulative volume that influenced it.
• Reject model-authored declassification and human approvals that are not bound to a typed action digest.
• Release only after hostile path tests demonstrate denial, revocation, replay resistance, receipts and recovery.

Glossary

Actor

The workload or human that performs an action.

Subject

The person or entity whose authority, data or interest the task represents.

Confused deputy

A component induced to use its own authority on a target or purpose selected by a less-trusted party.

Capability

An unforgeable, narrowly scoped grant of authority to act on a specified object or class of objects.

Flow label

Metadata constraining where information derived from a source may travel.

Declassification

An explicitly authorised transformation that permits information to move to a less restrictive label.

Path envelope

The carried subject, purpose, labels, provenance, budget, approvals and receipts used to evaluate a complete route.

Verified outcome

Independent readback establishing what actually changed after a tool accepted an action.

References

1. Hardy, N. (1988). The Confused Deputy: or why capabilities might have been invented. ACM SIGOPS Operating Systems Review, 22(4), 36–38.
2. Lampson, B. W. (1973). A Note on the Confinement Problem. Communications of the ACM, 16(10), 613–615.
3. Saltzer, J. H., & Schroeder, M. D. (1975). The Protection of Information in Computer Systems. Proceedings of the IEEE, 63(9), 1278–1308.
4. Denning, D. E. (1976). A Lattice Model of Secure Information Flow. Communications of the ACM, 19(5), 236–243.
5. Myers, A. C. (1999). JFlow: Practical Mostly-Static Information Flow Control. POPL.
6. Sabelfeld, A., & Myers, A. C. (2003). Language-Based Information-Flow Security. IEEE Journal on Selected Areas in Communications, 21(1), 5–19.
7. Miller, M. S., Yee, K-P., & Shapiro, J. S. (2003). Capability Myths Demolished. Johns Hopkins University Systems Research Laboratory.
8. Murray, T. et al. (2013). seL4: From General Purpose to a Proof of Information Flow Enforcement. IEEE Symposium on Security and Privacy.
9. Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). NIST SP 800-207: Zero Trust Architecture. National Institute of Standards and Technology.
10. Chandramouli, R., & Butcher, Z. (2023). NIST SP 800-207A: A Zero Trust Architecture Model for Access Control in Cloud-Native Applications. National Institute of Standards and Technology.
11. Jones, M., Nadalin, A., Campbell, B., Bradley, J., & Mortimore, C. (2020). RFC 8693: OAuth 2.0 Token Exchange. IETF.
12. Lodderstedt, T., Bradley, J., Labunets, A., & Fett, D. (2025). RFC 9700: Best Current Practice for OAuth 2.0 Security. IETF.
13. SPIFFE Project. SPIFFE concepts and workload identity.
14. Amazon Web Services. The confused deputy problem. AWS Identity and Access Management documentation.
15. Greshake, K. et al. (2023). Not What You’ve Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection.
16. OWASP GenAI Security Project. LLM01:2025 Prompt Injection.
17. Model Context Protocol. Security Best Practices, including confused-deputy protections for OAuth proxy flows.
18. Microsoft. Workload identities. Microsoft Entra Workload ID documentation.