Network Working Group J. Lee Internet-Draft C. Yoo Intended status: Standards Track M. Kim Expires: 10 April 2027 W. Seo SSenStone Inc. 7 October 2026 Per-Call Proof for Local Tool Invocation by AI Agents draft-lee-wimse-local-tool-call-proof-00 Abstract 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 This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-lee-wimse-local-tool-call- proof/. Discussion of this document takes place on the Workload Identity in Multi System Environments (WIMSE) Working Group mailing list (mailto:wimse@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/wimse/. Subscribe at https://www.ietf.org/mailman/listinfo/wimse/. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Lee, et al. Expires 10 April 2027 [Page 1] Internet-Draft Local Tool Call Proof October 2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 10 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Threat Model and Deployment Assumptions . . . . . . . . . . . 5 3.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Isolation Assumption . . . . . . . . . . . . . . . . . . 5 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 6 5. Action Digest . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Call Authority . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. General Requirements . . . . . . . . . . . . . . . . . . 7 6.2. Issue . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.3. Verify . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.4. Policy Integrity . . . . . . . . . . . . . . . . . . . . 9 7. Tool Server Enforcement . . . . . . . . . . . . . . . . . . . 9 8. Approval-Bound Actions . . . . . . . . . . . . . . . . . . . 10 9. Evidence Type Profiles . . . . . . . . . . . . . . . . . . . 10 10. Binding for the MCP stdio Transport . . . . . . . . . . . . . 10 10.1. Capability Advertisement . . . . . . . . . . . . . . . . 11 10.2. Carrying the Proof . . . . . . . . . . . . . . . . . . . 11 10.3. Rejection . . . . . . . . . . . . . . . . . . . . . . . 11 Lee, et al. Expires 10 April 2027 [Page 2] Internet-Draft Local Tool Call Proof October 2026 11. Relationship to Other Work . . . . . . . . . . . . . . . . . 12 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 15.1. Normative References . . . . . . . . . . . . . . . . . . 13 15.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Example Flow . . . . . . . . . . . . . . . . . . . . 16 Appendix B. Implementation Status . . . . . . . . . . . . . . . 16 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 16 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction The AI Identity Management System [I-D.ietf-wimse-aims] 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 [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" [MCP-AUTHZ]. The MCP local server guidance describes the agent client and a stdio server as sharing one trust domain [MCP-LOCAL]. 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. Lee, et al. Expires 10 April 2027 [Page 3] Internet-Draft Local Tool Call Proof October 2026 This document specifies: 1. a canonical *action digest* that identifies exactly one tool invocation (Section 5); 2. a *Call Authority* outside the agent process that issues and verifies per-call proofs (Section 6); 3. an *enforcement obligation* on tool servers to reject invocations without a valid proof (Section 7); 4. requirements for *evidence type profiles* (Section 9); and 5. a *binding for the MCP stdio transport* (Section 10). 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. 2. 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 [RFC2119] [RFC8174] 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. Lee, et al. Expires 10 April 2027 [Page 4] Internet-Draft Local Tool Call Proof October 2026 Action Digest: A canonical hash of an invocation's method, tool name and arguments (Section 5). Evidence Type: An identifier naming the format and semantics of a Call Proof, defined by an evidence type profile (Section 9). 3. Threat Model and Deployment Assumptions 3.1. 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. 3.2. 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 [I-D.ietf-wimse-aims]. * Compromise of the Call Authority or of the policy signing key. * Prevention of prompt injection itself, and actions that the policy permits. 3.3. 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 Lee, et al. Expires 10 April 2027 [Page 5] Internet-Draft Local Tool Call Proof October 2026 T1, T3 and T4, where the Agent's code is intact but its decisions are not. 4. Architecture Overview +---------+ (1) issue(method,name,args) +----------------+ | Agent | -----------------------------> | 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) Figure 1: Per-call proof flow 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. Lee, et al. Expires 10 April 2027 [Page 6] Internet-Draft Local Tool Call Proof October 2026 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. 5. Action Digest The Action Digest identifies exactly one invocation. It is computed as: action_digest = BASE64URL( SHA-256( JCS( { "method": , "name": , "arguments": } ) ) ) where: * JCS is the JSON Canonicalization Scheme [RFC8785]; * SHA-256 is as defined in [RFC6234]; * BASE64URL is base64url encoding without padding (Section 5 of [RFC4648]). The arguments MUST be taken exactly as transmitted, as a JSON [RFC8259] 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 ([MCP-SEP-2787], [MCP-SEP-2672]); aligning on one definition allows evidence produced under those proposals to serve as Evidence Types under this document. 6. Call Authority 6.1. 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. Lee, et al. Expires 10 April 2027 [Page 7] Internet-Draft Local Tool Call Proof October 2026 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. 6.2. Issue An issue request carries the intended invocation: { "jsonrpc": "2.0", "id": 1, "method": "callProof/issue", "params": { "method": "tools/call", "name": "read_file", "arguments": { "path": "repo/src/main.ts" }, "server": "filesystem" } } 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 [SPIFFE]. 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 (Section 8). 5. Otherwise returns { "type": "", "value": "", "expiresAt": "" } [RFC3339]. 6.3. Verify A verify request carries the Action Digest computed by the Tool Server and the evidence received: { "jsonrpc": "2.0", "id": 2, "method": "callProof/verify", "params": { "actionDigest": "", "server": "filesystem", "evidence": { "type": "", "value": "" } } } The Call Authority returns { "valid": true } or { "valid": false, "reason": "" }, where reason is one of invalid, expired, replayed, mismatch or unknownType. The Call Authority MUST: Lee, et al. Expires 10 April 2027 [Page 8] Internet-Draft Local Tool Call Proof October 2026 * 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. 6.4. 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. 7. 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 Section 3. 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. Lee, et al. Expires 10 April 2027 [Page 9] Internet-Draft Local Tool Call Proof October 2026 8. 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. 9. 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 [MCP-SEP-2787]; * a passkey approval for approval-bound actions, aligned with [MCP-SEP-2672]; and * a compact one-time authentication code derived inside a hardware root of trust, in the lineage of HOTP [RFC4226] and TOTP [RFC6238], to be specified separately. 10. Binding for the MCP stdio Transport Lee, et al. Expires 10 April 2027 [Page 10] Internet-Draft Local Tool Call Proof October 2026 10.1. Capability Advertisement An MCP server that supports this mechanism advertises the extension io.modelcontextprotocol/call-proof in its capabilities: { "capabilities": { "tools": {}, "extensions": { "io.modelcontextprotocol/call-proof": { "required": true, "methods": ["tools/call"], "authority": "unix:///run/mcp-call-authority.sock" } } } } required set to true selects enforcement as described in Section 7; 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. 10.2. Carrying the Proof The Call Proof is carried in the request _meta object: { "jsonrpc": "2.0", "id": 7, "method": "tools/call", "params": { "name": "read_file", "arguments": { "path": "repo/src/main.ts" }, "_meta": { "io.modelcontextprotocol/callProof": { "type": "com.example/token", "value": "" } } } } For MCP, the Action Digest method is the JSON-RPC method, the name is params.name, and the arguments are params.arguments. 10.3. Rejection A rejected invocation returns a JSON-RPC error whose data.reason is missing, authorityUnavailable, or a reason returned by the Call Authority: { "jsonrpc": "2.0", "id": 7, "error": { "code": -32021, "message": "Call proof rejected", "data": { "reason": "missing" } } } 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 [MCP-SEP-1763]. Lee, et al. Expires 10 April 2027 [Page 11] Internet-Draft Local Tool Call Proof October 2026 11. Relationship to Other Work AIMS [I-D.ietf-wimse-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 [RFC9449] and HTTP Message Signatures [RFC9421] 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 [MCP-SEP-2787] and per-call human approval [MCP-SEP-2672]. 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. 12. 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 (Section 8), 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 Section 3.3. 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. Lee, et al. Expires 10 April 2027 [Page 12] Internet-Draft Local Tool Call Proof October 2026 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. 13. 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. 14. IANA Considerations This document has no IANA actions. Evidence Types use namespaced identifiers under domains controlled by profile authors. 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Lee, et al. Expires 10 April 2027 [Page 13] Internet-Draft Local Tool Call Proof October 2026 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . 15.2. Informative References [I-D.ietf-wimse-aims] Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Identity Management System", Work in Progress, Internet-Draft, draft-ietf- wimse-aims-00, 15 September 2026, . [MCP] Model Context Protocol, "Model Context Protocol Specification, version 2026-07-28", 28 July 2026, . [MCP-AUTHZ] Model Context Protocol, "Model Context Protocol: Authorization", 28 July 2026, . Lee, et al. Expires 10 April 2027 [Page 14] Internet-Draft Local Tool Call Proof October 2026 [MCP-LOCAL] Model Context Protocol, "Model Context Protocol: Local Server Security", n.d., . [MCP-SEP-1763] Model Context Protocol contributors, "SEP-1763: Interceptors for Model Context Protocol", n.d., . [MCP-SEP-2672] Model Context Protocol contributors, "SEP-2672: Per-Call Passkey Verified Approval for MCP Tool Calls", n.d., . [MCP-SEP-2787] Model Context Protocol contributors, "SEP-2787: Tool Call Attestation", n.d., . [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, "HOTP: An HMAC-Based One-Time Password Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, . [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: Time-Based One-Time Password Algorithm", RFC 6238, DOI 10.17487/RFC6238, May 2011, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . Lee, et al. Expires 10 April 2027 [Page 15] Internet-Draft Local Tool Call Proof October 2026 [SPIFFE] Cloud Native Computing Foundation, "Secure Production Identity Framework for Everyone (SPIFFE)", n.d., . Appendix A. 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. Appendix B. Implementation Status This section records the status of known implementations per [RFC7942] 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. Appendix C. 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. Lee, et al. Expires 10 April 2027 [Page 16] Internet-Draft Local Tool Call Proof October 2026 * 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. Authors' Addresses Jaebin Lee SSenStone Inc. Korea, Republic of Email: jblee@ssenstone.com Chang-Hun Yoo SSenStone Inc. Korea, Republic of Email: chyoo@ssenstone.com MinGyu Kim SSenStone Inc. Korea, Republic of Email: mgkim@ssenstone.com WooYong Seo SSenStone Inc. Korea, Republic of Email: wyseo@ssenstone.com Lee, et al. Expires 10 April 2027 [Page 17]