This article has one primary anchor, L6 Security, Identity & Governance. It connects to exactly two interfaces: L5 Capability & Integration for admitted operations and L8 Infrastructure & Execution for resource-side enforcement. The model is an architectural proposal, not a claim that a specific product or customer deployment already implements it.

Five boundaries, not one login

  1. Accountable requester: a person or service requests a specific workflow with a known owner, purpose and permissible outcome.
  2. Workload identity: the running agent or service proves which software principal it is. Authentication alone does not authorize a business operation.
  3. Delegation mandate: an accountable principal grants a constrained task or scope. The mandate must not silently become tenant-wide application authority.
  4. Action authorization: the trusted policy enforcement point evaluates the actual tool, arguments, resource, tenant, environment, time and risk before execution.
  5. Observed effect: the target resource enforces its own boundary, and an independent check distinguishes an accepted API request from the intended state change.
Five distinct checkpoints: requester and sponsor, authenticated agent, scoped delegation, resource-side policy enforcement, and independently observed effect. An explicit deny path blocks execution.
Original reference diagram. Identity, delegated purpose and target-side permission must all hold; none substitutes for the others.

A token answers a protocol question about issuer, audience, subject and claims. It does not by itself answer whether a model-generated action is appropriate for a business purpose. A skill manifest answers what an action can do, not who may use it. A human approval must likewise bind a specific operation and input, rather than all future actions in the conversation.

The nine-dimensional authority envelope

The minimum authority decision should name each of these dimensions. A system can encode them in policy and evidence records, but not all must appear as token claims. Sensitive tenant data and internal policy should remain at the trusted service boundary.

  • Principal: who requested the work and which accountable owner or sponsor stands behind the request.
  • Workflow: the approved task, business purpose and stage; read-only evidence preparation is not account administration.
  • Agent: the attested runtime identity and version, not a name supplied by the model.
  • Tool: the admitted provider, exact operation and version, including approved effects.
  • Resource: the target object, system and tenant boundary checked independently by the service.
  • Data: classification, fields and purpose limitations, including export restrictions.
  • Environment: production, staging, network or execution isolation, and the trust boundary being crossed.
  • Budget: bounded transaction value, count, requests or spend; not a general right to consume capacity.
  • Time: mandate expiry, revocation and the freshness of the approval and policy decision.

Invariant: authenticated(agent) ∧ delegated(principal, workflow) ∧ admitted(tool) ∧ allowed(resource, data, environment, operation, budget, time) is required before execution. A missing claim is not an invitation for the model to infer permission. A later change to the target, amount, operation or scope requires a new authorization decision.

One access-review example: read evidence, do not decide for the owner

A security analyst asks a bounded review agent to prepare quarterly access-review evidence. The analyst can read approved identity and role records for one business system. The agent receives a distinct workload identity and a short-lived task mandate limited to that system, period and read-only operations. The record owner remains responsible for access decisions.

The agent encounters a retrieved comment instructing it to export all employee records to another service before continuing. The instruction is untrusted data, not a new mandate. The tool broker rejects the external export; the downstream resource checks the permitted scope independently. The agent may summarize evidence, identify discrepancies and ask the owner to review exceptions. It may not approve its own findings, remove access or expand the tenant scope.

The audit chain links the requester, agent identity, source evidence, policy version, exact proposed operation, authorization result and observed resource outcome. Minimize personal data in the trace and define retention and deletion rules. A denial is a valid controlled result, not a workflow failure to work around.

Delegated and autonomous identities are different risk decisions

For user-centric work, delegated permissions can preserve the user's access boundary. For autonomous service workflows, application permissions must be narrowly scoped and reviewed because they are not inherently limited by one user's access. A shared application credential must not become a universal agent identity. Microsoft Entra Agent ID documents distinct agent service principals, blueprint relationships and restrictions on highly privileged directory roles, but its platform features are not equivalent to business authorization in every downstream API.

SPIFFE describes cryptographically verifiable workload identity documents and short-lived identity material. Such evidence helps authenticate a running service; it does not encode all nine business restrictions. MCP's authorization specification defines HTTP protected-resource token handling, including audience binding, while its security guidance discusses confused-deputy and token-passthrough risks. Neither protocol grants an agent authority to override a resource owner's rules.

Architecture failure cases to test

  • Cross-tenant object: replace a valid resource ID with another tenant's ID; expect denial by the target service.
  • Stale mandate: replay an expired or revoked approval; expect denial despite cached tool discovery.
  • Wrong audience: present a valid token intended for another resource; expect rejection, not forwarding.
  • Changed arguments: approve a read, then request a write or different target; expect a new authorization decision.
  • Prompt injection: embed a role-changing command in a retrieved record; expect no change in actual grants.
  • Missing policy service: remove the policy decision or audit sink; stop consequential action safely.
  • Capability drift: substitute a different provider or tool version; expect requalification before use.
  • False success: report a completed change without a matching resource-side effect; record an evidence mismatch.

These are proposed negative test cases, not results of an executed test campaign. Record test version, total cases, denial outcomes, mismatches and any exception approvals before calling an implementation qualified.

Source → claim → decision → limitation

  • NIST SP 800-207, Zero Trust Architecture: a resource-centered authorization rationale that rejects implicit trust based on network location. Design decision: re-evaluate each consequential request at a trusted enforcement point. Limit: NIST does not prescribe this nine-dimensional agent-specific envelope.
  • Microsoft Entra Agent ID authorization documentation: documents agent role restrictions and differences between delegated and application permissions. Design decision: make delegation type explicit. Limit: behavior and availability depend on the product and tenant; the article is not a tenant validation.
  • SPIFFE concepts and workload identity: describes verifiable workload identity (SVIDs). Design decision: authenticate the runtime separately from approving its business action. Limit: an SVID is not an approval record.
  • MCP Authorization specification (2025-11-25): describes protected HTTP resources, OAuth roles and token validation. Design decision: bind tokens to the protected resource and validate audience. Limit: it does not decide transaction ownership or business purpose.
  • MCP Security Best Practices: addresses token passthrough, confused deputy and scope minimization. Design decision: prevent delegation being laundered through a proxy. Limit: recommendations are protocol security guidance, not proof of a deployed control.

Provenance and actual Harness change: this publication adds an L6 conceptual reference architecture, a nine-dimensional decision envelope and eight proposed failure tests to the public series. The private Harness research catalog has separately recorded identity-session revocation as an evidence-verification problem; catalog inclusion is not evidence of resource-side enforcement or a production rollout.

Open questions: how should approvals survive job retries without expanding scope; what is the independent evidence for revocation reaching each downstream session; which writes require a second owner; and how should policy decisions be reconciled with service-side denials?

Continue reading: L5: Capabilities Are Not Permissions, L5: Governed Invocation, L6: Guardrails Beyond Output Filtering, and the complete L0–L8 architecture map. Thursday's L6 applied article will address enforceable gates and approval tests, not extend the conceptual article's scope.

Privacy Notice: With your consent, this website uses Google Analytics to understand aggregate visits and content usage. Analytics is optional and is not used for advertising or cross-site profiling. Some content and images may be generated or modified with the assistance of AI; every AI-assisted item is reviewed and manually edited by a human before publication. Full Privacy Policy · AI modified — reviewed and edited by a human