]> SSenStone Inc.

Korea, Republic of jblee@ssenstone.com

SSenStone Inc.

Korea, Republic of chyoo@ssenstone.com

SSenStone Inc.

Korea, Republic of mgkim@ssenstone.com

SSenStone Inc.

Korea, Republic of wyseo@ssenstone.com

Security Network Working Group AI agent workload identity tool invocation Model Context Protocol proof of authorization AI agents increasingly act through local tool servers that run on the same host and are reached over inter-process channels such as the stdio transport of the Model Context Protocol (MCP). These channels are outside the scope of HTTP-based authorization: the tool server cannot tell whether a given invocation passed any policy decision, and reusable credentials typically sit in the agent's process memory. This document defines a per-call proof for local tool invocation. A Call Authority that runs outside the agent process evaluates policy, issues a short-lived, single-use proof bound to the exact tool name and arguments through a canonical action digest, and verifies that proof on behalf of the tool server. The tool server rejects invocations whose proof is missing or does not verify. The proof format is opaque to the agent and the tool server; concrete formats are defined as evidence type profiles. An MCP stdio binding is provided. About This Document Status information for this document may be found at . Discussion of this document takes place on the Workload Identity in Multi System Environments (WIMSE) Working Group mailing list (), which is archived at . Subscribe at .

Introduction The AI Identity Management System composes workload identity, short-lived credentials, transport and application layer authentication, and OAuth-based delegation into a model for authenticating and authorizing AI agents. Its focus is on interactions that cross network boundaries. A large share of agent actions, however, never cross a network boundary. An agent host commonly spawns local tool servers (filesystem access, shell execution, database and SaaS connectors) and talks to them over a local inter-process channel. In MCP , this is the stdio transport, and the authorization specification states that implementations using it "SHOULD NOT follow this specification, and instead retrieve credentials from the environment" . The MCP local server guidance describes the agent client and a stdio server as sharing one trust domain . That model is adequate for a single user on a personal device. It is not adequate when:

• an agent host runs on shared infrastructure and acts on behalf of many users;
• local tool servers hold long-lived credentials and broad filesystem access; and
• the agent's decisions are driven by untrusted content such as issues, pull requests, documents and web pages.

In that setting the agent is the most exposed component, and the local tool server is the last point at which an invocation can be checked before it reaches a resource. Network enforcement points never see calls to local resources such as files and shell commands. This document specifies:

1. a canonical action digest that identifies exactly one tool invocation ();
2. a Call Authority outside the agent process that issues and verifies per-call proofs ();
3. an enforcement obligation on tool servers to reject invocations without a valid proof ();
4. requirements for evidence type profiles (); and
5. a binding for the MCP stdio transport ().

The mechanism does not prevent prompt injection. It confines the effects of an injected or compromised agent to actions that policy permits, removes reusable secrets from the agent process, and makes every invocation attributable.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Agent:

A software component that decides, typically with the help of a language model, which tools to invoke and with which arguments. In MCP terms, the client embedded in an agent host.

Tool Server:

A local process that executes tool invocations requested by the Agent, for example an MCP server reached over stdio.

Call Authority:

A component that runs outside the Agent process, evaluates Policy, issues Call Proofs and verifies them. It holds all key material used for Call Proofs.

Policy:

A signed document loaded by the Call Authority that states which callers may invoke which tools with which argument constraints, and which actions require human approval. The policy language is out of scope.

Call Proof:

A short-lived, single-use value that commits to one Action Digest and attests that the Call Authority authorized that invocation.

Action Digest:

A canonical hash of an invocation's method, tool name and arguments ().

Evidence Type:

An identifier naming the format and semantics of a Call Proof, defined by an evidence type profile ().

Threat Model and Deployment Assumptions

In Scope T1. Injected instructions. Content processed by the Agent causes it to request a tool invocation outside its intended role, for example reading a credential file and sending its contents through another tool. T2. Theft of reusable secrets. Code execution inside the Agent process (for example through a compromised dependency) is used to extract credentials that remain usable after the compromise ends. T3. Policy bypass and proof reuse. An invocation is sent without passing a policy check, or a proof obtained for one invocation is presented for another. T4. Policy tampering. The policy is modified so that a denied action becomes allowed.

Out of Scope

• A malicious or compromised Tool Server. A Tool Server that ignores verification cannot be constrained by this mechanism.
• Credentials that the Tool Server itself uses to reach remote resources. Those are covered by network-level controls and the mechanisms in .
• Compromise of the Call Authority or of the policy signing key.
• Prevention of prompt injection itself, and actions that the policy permits.

Isolation Assumption Protection against T2 requires that the Agent run in a separate isolation boundary (a different operating system user, container or virtual machine) from the Tool Server and the Call Authority. If they share one boundary, code execution in the Agent can read the Tool Server's environment or start a Tool Server without verification. In that configuration this mechanism still addresses T1, T3 and T4, where the Agent's code is intact but its decisions are not.

Architecture Overview

Per-call proof flow | Call Authority | | (no | <----------------------------- | policy, keys, | | secrets)| (2) Call Proof | replay cache, | +---------+ | audit log | | +----------------+ | (3) invocation + Call Proof ^ | v | | +-------------+ (4) verify(action_digest, proof) | | | Tool Server | -----------------------------------+ | | + enforce- | <---------------------------------------+ | ment hook | (5) valid / invalid(reason) +-------------+ | (6) execute only if valid v local resources (files, shell, local services) ]]>

1. The Agent asks the Call Authority to issue a proof for an intended invocation.
2. The Call Authority identifies the calling process from the platform, evaluates Policy and, if allowed, returns a Call Proof. The proof never passes through the Call Authority again on the way to the Tool Server.
3. The Agent sends the invocation to the Tool Server with the Call Proof attached.
4. The Tool Server computes the Action Digest from the invocation as received and asks the Call Authority to verify the proof against it.
5. The Call Authority checks binding, freshness and single use, records the decision, and answers.
6. The Tool Server executes the invocation only if the answer is valid.

Verification is delegated to the Call Authority so that the Tool Server needs no key material and no knowledge of evidence formats. This allows symmetric and asymmetric evidence types to coexist and keeps replay tracking and audit in one place.

Action Digest The Action Digest identifies exactly one invocation. It is computed as: , "name": , "arguments": } ) ) ) ]]> where:

• JCS is the JSON Canonicalization Scheme ;
• SHA-256 is as defined in ;
• BASE64URL is base64url encoding without padding ().

The arguments MUST be taken exactly as transmitted, as a JSON value. Implementations MUST NOT normalize argument values (for example by resolving file system paths) before computing the digest. Semantic normalization belongs to policy evaluation, not to the digest. The same construction is used by proposals in the MCP community for argument commitments (, ); aligning on one definition allows evidence produced under those proposals to serve as Evidence Types under this document.

Call Authority

General Requirements The Call Authority MUST NOT run inside the Agent process. The Agent MUST NOT have access to any key material used to create or verify Call Proofs. Where available, keys SHOULD be generated and used inside a hardware root of trust (for example a TPM) so that they are never exported. The Call Authority exposes a local interface using JSON-RPC 2.0 messages over a local endpoint such as a Unix domain socket or a named pipe. The endpoint MUST NOT be reachable from outside the host.

Issue An issue request carries the intended invocation: The Call Authority:

1. MUST establish the identity of the calling process from the platform, for example from the peer credentials of the local socket or from a workload identity issued to that process such as a SPIFFE ID . It MUST NOT rely on an identity asserted in the request body.
2. MUST evaluate Policy for that identity, target server, tool and arguments.
3. MUST return an error and MUST NOT issue a proof if Policy denies the invocation.
4. MAY return an approval-required result when Policy requires human approval ().
5. Otherwise returns { "type": "<evidence type>", "value": "<proof>", "expiresAt": "<RFC 3339 timestamp>" } .

Verify A verify request carries the Action Digest computed by the Tool Server and the evidence received: ", "server": "filesystem", "evidence": { "type": "", "value": "" } } } ]]> The Call Authority returns { "valid": true } or { "valid": false, "reason": "<reason>" }, where reason is one of invalid, expired, replayed, mismatch or unknownType. The Call Authority MUST:

• treat the Action Digest supplied by the Tool Server as authoritative;
• return mismatch if the proof does not commit to that Action Digest;
• return expired if the proof is outside its validity window;
• accept a given proof at most once and return replayed for later attempts; and
• record each issue and verify decision, including caller identity, server, tool, Action Digest, result, approver if any, and time.

Policy Integrity Policy SHOULD be signed. The verification key for Policy SHOULD be fixed when the Call Authority is installed and SHOULD NOT be delivered together with the Policy. The Call Authority SHOULD reject a Policy whose version is lower than the currently loaded one, and MUST deny all issuance when no valid Policy is loaded.

Tool Server Enforcement A Tool Server that requires Call Proofs MUST, for each covered invocation and before any side effect:

1. compute the Action Digest from the invocation as received;
2. reject the invocation if no Call Proof is present;
3. otherwise call verify and reject the invocation unless the result is valid; and
4. reject the invocation if the Call Authority cannot be reached (fail closed).

A Tool Server MAY operate in an audit mode in which it verifies proofs that are present and executes invocations without a proof, to support staged deployment. Audit mode does not provide the protections described in . For tools that operate on file system paths, Tool Servers SHOULD resolve and re-check paths at execution time where tool semantics allow, to reduce time-of-check to time-of-use risk.

Approval-Bound Actions Policy MAY mark actions as requiring human approval. For such actions, the Call Authority MUST NOT issue a Call Proof until an approver designated by Policy has approved the specific Action Digest. Evidence type profiles define the approval channel. Profiles SHOULD present a human-readable summary of the action to the approver and SHOULD bind the approval to the Action Digest. Approval channels that do not require the Call Authority to accept inbound network connections are RECOMMENDED.

Evidence Type Profiles An evidence type profile MUST specify:

• the Evidence Type identifier, using a namespaced form under a domain controlled by the profile author (for example com.example/token);
• the format of the proof value;
• how the proof commits to the Action Digest;
• the validity window, which SHOULD be 30 seconds or less;
• how keys are provisioned to and protected by the Call Authority; and
• how single use is enforced.

Profiles SHOULD keep proof values compact. Local channels such as stdio carry one message per line, and per-call evidence such as certificate chains adds overhead to every invocation. Anticipated profiles include (informative):

• a JWS envelope issued by the Call Authority, aligned with ;
• a passkey approval for approval-bound actions, aligned with ; and
• a compact one-time authentication code derived inside a hardware root of trust, in the lineage of HOTP and TOTP , to be specified separately.

Binding for the MCP stdio Transport

Capability Advertisement An MCP server that supports this mechanism advertises the extension io.modelcontextprotocol/call-proof in its capabilities: required set to true selects enforcement as described in ; false selects audit mode. methods lists covered request methods; tools/call MUST be included. authority optionally names the Call Authority endpoint. The extension identifier is shown with the MCP official prefix for illustration. Until the extension is accepted by the MCP project, implementations SHOULD use an identifier under their own vendor prefix.

Carrying the Proof The Call Proof is carried in the request _meta object: " } } } } ]]> For MCP, the Action Digest method is the JSON-RPC method, the name is params.name, and the arguments are params.arguments.

Rejection A rejected invocation returns a JSON-RPC error whose data.reason is missing, authorityUnavailable, or a reason returned by the Call Authority: The numeric error code is a placeholder pending coordination with the MCP project. Verification MAY be implemented as a server-side validator in the MCP interceptor model .

Relationship to Other Work AIMS addresses agent identity, credential provisioning, authentication and delegation across network boundaries. This document addresses the local invocation boundary that AIMS does not cover, and reuses workload identity for caller identification at the Call Authority. DPoP and HTTP Message Signatures bind proofs to HTTP requests. Local inter-process channels have no HTTP request to bind to, and DPoP does not cover the request content. The Action Digest plays the role of the bound request representation. Proposals in the MCP community define argument-bound attestation for audit and per-call human approval . This document adds the enforcement obligation on the tool server and the requirement that issuing keys reside outside the agent process, and treats those formats as candidate evidence types.

Security Considerations The unit of protection is a single tool invocation. Agents decompose a user request into separate invocations, and each one is authorized and verified independently, so a request that combines permitted and forbidden steps is stopped at the forbidden step. Most tool servers expose one operation per tool (for example, separate tools to read, write or send), which lets Policy decide by tool name and arguments. General-purpose tools, such as shell execution, arbitrary database queries or code execution, and workflow tools that perform several effects in one invocation, cannot be separated this way. Policy for such tools needs to evaluate their arguments, and deployments should treat them as high risk, subject them to approval (), or not grant them to roles that do not need them. When a later invocation in a sequence is denied, earlier invocations have already run. Data they returned remains available to the Agent, although the denied invocation cannot carry it further. This document does not provide authorization of a multi-step plan as a whole. The protections of this mechanism depend on the isolation assumption in . Deployments that cannot separate the Agent from the Tool Server and Call Authority obtain protection against injected instructions and proof reuse, but not against extraction of Tool Server credentials by code running in the Agent process. The Call Authority is a high-value component. Its compromise is equivalent to Policy compromise. Hardware-protected keys, signed Policy with rollback protection, and fail-closed behavior limit the impact of partial failures but not of full compromise. JCS removes representation differences (member order, whitespace, number and string encoding) but not semantic equivalence. Two semantically equal argument sets can produce different digests; Policy must be written against arguments as transmitted or must evaluate semantic forms explicitly. Short validity windows and single-use enforcement limit replay. Clock skew between the Call Authority's issue and verify operations is not a concern because both run in the same component. Fail-closed behavior makes the Call Authority a dependency for every covered invocation. Its availability should be monitored like any other enforcement component. Approval channels can be targeted by social engineering. Summaries shown to approvers should be generated by the Call Authority from the invocation, not supplied by the Agent.

Privacy Considerations The Call Authority records caller identity, tool names, Action Digests and approver identities. The audit log can reveal user activity and should be protected and retained according to applicable policy. Action Digests do not reveal argument values directly, but low-entropy arguments can be recovered by guessing; logs should be protected accordingly.

IANA Considerations This document has no IANA actions. Evidence Types use namespaced identifiers under domains controlled by profile authors.

References Normative References Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. Federal Information Processing Standard, FIPS JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Defakto Security AWS Zscaler Ping Identity OpenAI Okta This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. This document describes an algorithm to generate one-time password values, based on Hashed Message Authentication Code (HMAC). A security analysis of the algorithm is presented, and important parameters related to the secure deployment of the algorithm are discussed. The proposed algorithm can be used across a wide range of network applications ranging from remote Virtual Private Network (VPN) access, Wi-Fi network logon to transaction-oriented Web applications. This work is a joint effort by the OATH (Open AuTHentication) membership to specify an algorithm that can be freely distributed to the technical community. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. This memo provides information for the Internet community. This document describes an extension of the One-Time Password (OTP) algorithm, namely the HMAC-based One-Time Password (HOTP) algorithm, as defined in RFC 4226, to support the time-based moving factor. The HOTP algorithm specifies an event-based OTP algorithm, where the moving factor is an event counter. The present work bases the moving factor on a time value. A time-based variant of the OTP algorithm provides short-lived OTP values, which are desirable for enhanced security. The proposed algorithm can be used across a wide range of network applications, from remote Virtual Private Network (VPN) access and Wi-Fi network logon to transaction-oriented Web applications. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Model Context Protocol Model Context Protocol Model Context Protocol n.d. Model Context Protocol contributors n.d. Model Context Protocol contributors n.d. Model Context Protocol contributors n.d. Cloud Native Computing Foundation n.d.

Example Flow A code-review agent is permitted by Policy to read files under repo/ and to post review comments. Content in a pull request instructs it to read ~/.aws/credentials.

1. The Agent requests issue for read_file with path ~/.aws/credentials.
2. The Call Authority identifies the caller as the code-review agent, evaluates Policy, denies, and records the attempt.
3. If the Agent sends the invocation anyway, the Tool Server finds no Call Proof and rejects it.
4. If the Agent replays a proof issued earlier for repo/README.md, the Tool Server computes a different Action Digest and the Call Authority returns mismatch.

Implementation Status This section records the status of known implementations per and is to be removed before publication. A reference implementation consisting of a Call Authority daemon, MCP server-side enforcement, client-side issuance and two evidence type profiles is in development. Repository location: TBD.

Open Issues

• Whether the Call Authority interface belongs in this document or a companion document.
• Coverage of additional MCP methods such as resources/read and prompts/get.
• Error code coordination with the MCP project.
• Alignment of the Action Digest definition with MCP community proposals.
• Whether an IANA registry for Evidence Types is warranted.
• Plan-level authorization: evaluating a declared sequence of invocations before the first one runs, and its relation to intent declaration proposals in the OAuth working group.
• Guidance for tools that combine several effects in one invocation.

Acknowledgments TBD.