AAIF Working Group Security Recommendations for Agent Interoperability

AAIF’s security recommendations for agent interoperability address a blunt problem. Connecting agents is not the same as controlling them. Enterprises deploying MCP and A2A need portable identities, bounded delegation, per-action traceability, and evidence that can cross organizational boundaries. Those controls must work as one system, but the proposed Attestation and Evidence Working Group’s work is still unfinished and cannot yet protect them.

Why 2026 became the year enterprises had to take agent interoperability security seriously

MCP was contributed to AAIF in December 2025, removing it from single-vendor control. Google’s A2A formally joined on August 17, 2026, placing both protocols under one neutral governance umbrella. Enterprises could plan around a shared governance structure.

The protocols serve different parts of that architecture. MCP connects an agent to tools, data, and APIs, while A2A connects agents across framework and vendor boundaries. Mature multi-vendor programs need both layers to work together. IBM’s merger of its Agent Communication Protocol into A2A in August 2025 had already removed a competing specification.

AAIF’s August 13, 2026 announcement said it had 247 member organizations, including firms in financial services and technology leaders in Asia-Pacific. Its Platinum sponsors include AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI. Its Technical Committee sits above the Technical Steering Committees for each protocol, keeping decisions about the foundation separate from changes to the protocols. The governance now has real industry weight. But shared governance does not make a deployment secure. The working groups’ security recommendations need separate attention.

Why the protocol stack that needs governing was built with authorization as an afterthought

The MCP authorization specification defines an OAuth 2.1 framework but explicitly makes authorization optional. That leaves room for servers without authentication by design. A common connection protocol therefore does not guarantee a common security boundary. Enterprises must put in place controls that the protocol leaves optional.

Surapani et al. (2026) name tool invocation as the point where the key decision must be made. When an agent calls an external API, changes state, or starts a transaction, identity, intent, permission, provenance, and policy must converge. The authors find that few documented deployments reliably provide traceability, bounded delegation, and contestability from end to end. The weakness sits where software takes action. Protecting only the conversation with the agent leaves that decision point exposed.

OX Security disclosed a systemic flaw in Anthropic’s official MCP SDKs in April 2026. The STDIO transport passed configuration parameters straight to the host OS shell without sanitization, which left an estimated 200,000 instances vulnerable. A separate failure, CVE-2026-32211 in Azure MCP Server, involved information disclosure caused by missing authentication and had a CVSS score of 9.1. Trend Micro also found hundreds of MCP servers exposed to the open internet with no authentication.

An enterprise must control the boundary between a request and its execution. Identity is the starting point for that control because a permission decision needs a distinct actor to evaluate.

What the AAIF Identity and Trust Working Group actually requires enterprises to implement

The AAIF Identity and Trust Working Group’s core requirement is a distinct, portable, verifiable identity for every agent, bound to every action it takes. A repurposed service account is not enough. Each agent needs an owner, a record of its credential type, a schedule for credential rotation, and an authorized scope. Existing service accounts reused for agents must be re-scoped to the minimum permissions required for each specific task.

AAIF’s Autonomous Agent Interchange Format, an AAIF-IETF draft, states that secrets must not appear inline in agent documents. Its auth.env_var and auth.vault_ref fields hold references. Tools containing inline credential values must be rejected.

A2A v1.0 supplies a mechanism for portable identity through signed Agent Cards using JWS. These cards use trusted signing keys to authenticate an agent’s identity and metadata so they can be verified across vendors. Agent Cards also state which authentication schemes to use for discovery. Authorization remains the implementer’s job. Knowing which agent has arrived does not establish what that agent may do.

Surapani et al. define the principal hierarchy that those decisions must follow, from the human user through the operator or deployer, orchestrator agent, sub-agent, and tool endpoint. Every credential and permission decision must be traceable back through that chain. The CSA/Strata “Securing Autonomous AI Agents” survey report from February 2026 found that only 23% of organizations had a formal enterprise-wide agent identity strategy. An even smaller share were highly confident that their IAM infrastructure could handle agent identities.

How delegation and scope propagation work across multi-agent chains, and where they break

Delegation makes identity harder because one agent acts through another. The dangerous case is the “confused deputy,” where a server accepts tokens intended for a different service and forwards them unmodified. The server can then act without being bound by the authority granted to the request. A valid credential can then support the wrong action. Verifying identity alone does not prevent that mismatch.

MCP’s July 2026 specification update sets a concrete rule for authorization responses. Clients must validate the iss parameter when it is present, following RFC 9207. They must also reject a missing iss when the authorization server advertises support for it. Clients must also check audience binding through RFC 8707 resource parameter validation. These checks address which authorization server issued the response and which resource the authorization is intended for.

Delegated permissions need a separate boundary after token validation. Each subagent should receive only the permissions needed for its task, limited to that task’s duration, rather than inherit the orchestrator’s broader grants. Surapani et al. identify runtime enforcement and aggregation bounds as unresolved gaps. Policy enforcement points at tool-call depth are required but are rarely put in place, and permissions gathered across several hops can go beyond any one delegation grant. Local checks alone can miss the combined authority.

The Git MCP server vulnerabilities show why scope cannot remain an abstract policy. CVE-2025-68143 involved path traversal, CVE-2025-68144 argument injection, and CVE-2025-68145 repository scoping bypass, with public disclosure on January 20, 2026. These expose weaknesses at execution boundaries related to those exposed by token-forwarding failures. Teams must also set human approval gates for actions that are hard to undo, such as data deletion, external communication, and credential provisioning. The EU AI Act’s Article 14(4)(e) requires interruption capability for high-risk AI systems, so those systems must have a control that lets them halt safely.

AAIF governance does not standardize enterprise authorization policy. Both protocols leave those patterns to adopters, preserving protocol simplicity while leaving enterprises responsible for enforcement. IETF work is still developing, including WIMSE’s September 15, 2026 “AI Identity Management System” draft. The IESG approved the agentproto working group charter on October 8, 2026, but it had no associated working group documents as of October 9, 2026. Enterprises cannot treat future standardization as a substitute for implementing the AAIF recommendations and NIST NCCoE framework now.

Per-action traceability as a security requirement, not a compliance checkbox

A permission check without a reconstructable execution chain leaves a basic question unanswered afterward. Did the action stay within the authority the human actually delegated? The audit record must capture instructions, retrieved context, tool invocations and parameters, returned results, decisions, and human approvals or overrides. A record that merely says an agent succeeded cannot support that judgment.

The NIST NCCoE framework’s non-repudiation dimension requires accountability linking agent actions to the human authority that sanctioned them. This turns the principal hierarchy into a logging requirement. Surapani et al. likewise treat auditability and provenance as structural controls, requiring enough evidence to reconstruct whether a tool invocation was authorized and to contest it afterward. Traceability therefore supports enforcement. Without it, neither a delegation boundary nor an identity claim can be tested after the fact.

Tamper-proof logs and full OTEL, or OpenTelemetry, tracing provide the implementation pattern for distributed agent systems. A common telemetry standard allows the execution chain to remain reconstructable across vendor boundaries, where separate tracing conventions would otherwise break it. That record must include human intervention as well as agent activity. An approval or override is part of the authority chain.

Regulatory frameworks reinforce this security requirement. Healthcare, financial services, and government add obligations including PHI protection, immutable trade and decision logs, and public AI use case inventories. The AI Controls Matrix v1.0, published in July 2025, provides 243 control objectives across 18 security domains, with mappings to ISO 42001, the EU AI Act, and NIST AI 600-1. Enterprises can use those mappings to link AAIF audit requirements to the compliance programs they already have.

What the proposed Attestation and Evidence Working Group adds that the current framework cannot provide

Another organization cannot take an execution record on trust just because it comes from within an organization. That is the gap the proposed Attestation and Evidence Working Group addresses. Its draft charter aims to make “the actions, decisions, authorizations and outcomes of AI agents independently verifiable” across organizational boundaries without requiring a central authority. The group is still in draft charter. Its proposed scope is not an existing set of deliverables.

Signed Agent Cards do not close this gap. They authenticate identity and metadata at registration time, but they do not attest to a specific runtime action or the authorization chain behind it. An orchestrator in one organization may therefore recognize a subagent operated by another without having independently verifiable evidence of what it did.

The distinction becomes sharper when neither organization can assume the other’s logs or identity claims are trustworthy. Cross-organizational delegation leaves open who authorized an action, who is liable for it, and how the chain can be audited. The proposed group aims to resolve that uncertainty. Its attestation infrastructure must also account for short-lived, task-specific subagents. Evidence must also work for identities that last less time than traditional service accounts.

Stephen Chin of Neo4j filed a proposal for the Agent Context and Memory Working Group on October 15, 2026. Its proposed work includes interoperability and trust across agent harnesses, shared memory, provenance, access controls, privacy, and defenses against memory poisoning. Trustworthy evidence will have to address the context agents exchange as well as the actions they execute, but these proposals remain work to be developed.

How to turn the AAIF framework into an implementation roadmap for enterprise security and platform teams

The implementation priority is to connect the controls. Security, platform, and IAM teams should begin by inventorying agents and assigning each a distinct non-human identity, owner, and authorized scope. Replace inline credentials with references and reduce reused service accounts to task-specific permissions. That establishes the actors and grants the rest of the system must govern.

Next, enforce audience binding and issuer validation across MCP integrations using RFC 8707 and RFC 9207. Define delegation boundaries before deploying orchestrator-subagent patterns, including task-scoped, time-bounded permissions and the action categories requiring human approval. Neither should be treated as a substitute for the other, and runtime enforcement must reach the tool-call boundary.

Build the execution-chain audit trail from day one, with OTEL tracing across agent boundaries. Map those controls to the AICM and applicable regulatory requirements, including interruption capability and sector-specific obligations. For cross-organizational deployments, distinguish existing identity verification from the runtime evidence the proposed AE-WG aims to support. A unified platform approach is useful where it connects identity, authorization, and tracing across those boundaries, rather than leaving teams to reconcile separate records and policies.

Neutral governance alone would be a weak reason to invest. The July 28, 2026 MCP update and the NIST NCCoE concept paper give teams concrete controls to implement, providing a stronger reason to invest. Gartner warns that more than 40% of agentic AI projects risk cancellation by 2027 because of escalating costs, unclear business value, and inadequate risk controls. Interoperability earns a place in production when an enterprise can identify who acted, limit the authority used, reconstruct the result, and expose where cross-boundary proof is still missing.