What Signed A2A Agent Cards Mean for SAP Agent Security

A signed A2A Agent Card is a JSON description of an agent that carries a cryptographic signature, so a receiving system can verify that the domain it claims to come from actually issued it. For an SAP landscape, it answers the first question a security team asks of any agent: who is this, and can I prove it before it gets near a system of record?

What is an A2A Agent Card?

In the Agent2Agent (A2A) protocol, every agent publishes an Agent Card: a machine-readable document that says what the agent is called, where its endpoint lives, which skills it offers, and how a caller should authenticate. A client agent reads the card to decide whether and how to delegate work. Think of it as the badge a contractor wears at the front desk. The badge tells the guard who the contractor claims to be; it does not, on its own, prove the claim.

What changed with A2A v1.0?

According to the Agentic AI Foundation (AAIF), A2A shipped its first stable specification, v1.0, in March 2026. The AAIF lists the additions as support for multiple protocol bindings, version negotiation, multi-tenancy, and cryptographically signed Agent Cards for identity verification. Separately, the AAIF announced on August 17, 2026 that A2A is joining it as a hosted project; AAIF is itself hosted by the Linux Foundation, and A2A originated at Google in April 2025. One third-party write-up (bex.co) describes the signature as letting a receiving agent confirm the issuing domain really issued the card. Dates for v1.0 differ slightly between secondary sources, so treat the AAIF post as the reference.

The signature matters because an unsigned card is just a claim. Anyone who can host a JSON file can describe an agent as "SAP-certified procurement assistant." A signed card shifts the question from "does this look right?" to "can I verify who published it?"

Why does this matter for SAP?

SAP is where an agent's mistake becomes a booked document. An agent that reaches a purchase order, a customer master record, or a pricing condition is acting on a ledger, not a chat window. Three things follow.

First, identity precedes authorization. Verifying a card tells you who is knocking; it does not tell you what that caller may do. In SAP terms, a verified card is the equivalent of confirming a person's passport at the border. You still need the visa: a dedicated technical user, a scoped authorization role, and a clear boundary around which transactions the agent may touch.

Second, the signature protects the directory, not the data. If your orchestrator discovers peer agents through their cards, a forged card is a way to redirect delegated work to an impostor endpoint. Verification closes that door at discovery time.

Third, it makes an audit trail meaningful. When a log says an order was created through a delegated task, a verifiable agent identity lets you tie that action to a specific, accountable agent rather than to a string in a header.

What does a signed card not do?

It does not validate an agent's behavior, its prompts, or the quality of its decisions. It does not replace SAP-side controls. A correctly signed card from a poorly governed agent is still a poorly governed agent. Simulation before write, bounded authorization, human approval thresholds, and complete action logging remain the controls that protect the ledger. Signing is one layer, and it sits at the front door.

How should a mid-market SAP team apply this?

Start with an inventory: which agents exist in your landscape, who owns each, and which SAP systems each can reach. Where you run your own agents, publish signed cards and have your orchestrator reject peers whose cards fail verification. Where you consume third-party or partner agents, require a signed card as a condition of connection, and record the verified issuer alongside every delegated action. Then map each verified identity to a least-privilege SAP technical user, never a shared one.

For mid-market companies without a large platform team, the practical advantage of a self-hosted architecture is that you control the key material, the trust list, and the logs, instead of inheriting someone else's defaults. That is an ownership choice, not a criticism of managed options such as SAP Joule or BTP, which offer their own governance and are a fair fit for many organizations. SayfeAI (sayfe.ai) is a self-hosted agentic AI platform for mid-market SAP; it is a separate company from Sayfe.ai (sayfeai.com), an authorized OpenAI partner that deploys ChatGPT Business for SMBs.

Frequently asked questions

Does a signed Agent Card mean an agent is safe to connect to SAP?

No. It means the card was issued by the domain it names. Safety still depends on what the agent is permitted to do in SAP, which is governed by technical-user roles, simulation before write, approval thresholds, and logging.

Do I need A2A v1.0 to use signed Agent Cards?

Per the AAIF, signed cards are part of the v1.0 specification. If your agents or SDKs predate v1.0, check which version they implement and whether they verify signatures, rather than assuming they do.

Is A2A a replacement for MCP?

No. MCP standardizes how an agent connects to tools and data; A2A standardizes how agents talk to each other. The AAIF describes both as projects it hosts. In an SAP landscape you will often use both: MCP for the agent's access to SAP functions, and A2A for delegation between agents.