Disclaimer
This article is intended for informational purposes and reflects the state of published research and industry practice as of its publication date. It is not professional security advice. Your specific environment, threat model, and regulatory obligations will shape how these principles apply to your situation. The views and opinions expressed here are my own and do not represent the position of my employer, SAP, or any other affiliated organization.
For Security Leaders
An external agent can present valid credentials while your organization lacks a verified answer to who operates it. Changes in ownership or credentials can leave earlier acceptance decisions in use. Every external agent connection needs an owner who can justify and withdraw that acceptance.
What this means for your organization:
Accountability: Service access needs a verified operator and a named internal owner.
Continuity: Changes in ownership or credentials need review before earlier trust carries forward.
Exposure: Outdated identity decisions can leave access open after the relationship changes.
What to tell your teams:
Record which providers may connect and who approves each relationship.
Keep credentials out of model-visible records and retained outputs.
Define when ongoing requests need renewed identity checks and what happens during verification outages.
Test legitimate acceptance and rejection after key replacement or provider changes.
Who is calling? Establishing agent identity and trust
What your service has to decide
Google’s Agent Development Kit includes a helper that exposes an agent as a remote service and publishes its authentication requirements in discovery metadata. The helper’s documentation says the generated application does not enforce those requirements. Whoever deploys the agent has to add the check, and that documentation sent me looking at what the check must establish.
The check involves three parties. A provider runs the agent and answers for it. An issuer gives the agent its credential. It may be the provider or a separate organization. Your service receives the call. When a request arrives, your service needs three answers. First, does it accept this issuer? Second, which approved agent and provider does the credential belong to? Third, what happens when that relationship changes?
An agent name written into the request can’t answer the second question, because several agents can share one credential. The answers have to come from records your service controls. Most of those records already exist in enterprise identity systems as issuer trust configuration, application registrations and audit logs. Where those systems can’t express the link between an agent and its provider, you add attributes or checks. Either way, the records help only if callers can’t edit them and your service enforces what they say.
Decide which issuers you accept
Accepting an issuer and accepting a particular agent are separate decisions. The issuer may vouch for dozens of the provider’s services, and you want to approve one of them. I would record both decisions in the identity platform you already run: issuer trust configuration for the first and application registration for the second.
The first decision works like single sign-on. There, an identity provider (IdP) gives an identity assertion to an application, and the application decides whether to accept it. Agent services can present workload credentials, which identify running software. In both cases your service chooses which issuers it accepts and what their claims mean locally. Under this policy, an issuer you accept for the provider’s workloads has no authority to claim that one of your users approved anything.
Before accepting the issuer, verify both the provider and the issuer, since they may be different organizations. Record who on each side can approve the relationship and which claims your service will accept from that issuer. The agreement covers calls into your service only. When your agent calls the provider, the provider makes its own acceptance decision about your credentials.
Your service can then accept the issuer’s credentials in one of two ways. It can validate them directly, using verification keys and validation rules you approved. Or your own identity platform, if it supports token exchange, can validate the provider’s credential, apply your policy and issue a fresh token for your service. In the second case your service validates that local token: its issuer, signature, lifetime, intended recipient and any required proof that the caller holds the bound key.
Either way, your service must remember which keys belong to which issuer. The Secure Production Identity Framework for Everyone (SPIFFE), a workload identity standard, makes this explicit. A SPIFFE trust domain is an issuing namespace. Its bundle endpoint supplies the verification keys accepted for that domain. To federate with another trust domain, the SPIFFE specification requires you to configure that foreign trust domain, its bundle endpoint and how to authenticate that endpoint. Validators must keep each set of keys tied to its trust domain. If that tie is lost, a credential signed by one domain could pass as proof of an identity in another, and your service would accept a caller the real authority never vouched for.
Register the agent behind the credential
Accepting the issuer tells your service who may vouch for a caller. The next question is which of the issuer’s identities belongs to the agent you approved. The building blocks exist already. Enterprise identity platforms can manage application registrations and service identities. A workload identity control plane assigns identities to running software based on registered properties of the workload, such as its namespace or service account.
Store the link between that identity and the approved agent in a registry you already trust, such as an application registry or a directory accessed through the Lightweight Directory Access Protocol (LDAP), using existing fields or a schema extension. The entry ties the issuer and the workload or client identifier to the agent, its provider and its approved endpoints. An administrator verifies the provider during enrollment and controls changes to the entry. After authentication, your service looks the entry up. The lookup includes the issuer, so an identifier from another authority cannot match your approved agent even when the names are identical.
The entry also gives the agent continuity. The approved agent keeps its registered identity across approved restarts and migrations, while execution logs tell individual instances and runs apart. Ownership records, configuration history and identity audit logs should record when the provider or configuration changed. That history later lets you say which relationship your service had accepted at the time of a given event.
Neither side needs the other’s full enrollment record. Each organization should share only the identity and responsibility claims the other needs for its decision, and keep the full history in a protected internal record. Where the issuer supports recipient-scoped identifiers, meaning a different identifier for each recipient, use them to make the agent’s activity harder to correlate across services. A scoped identifier leaves the other fields of a signed assertion visible. What you disclose depends on which claims the issuer puts in the assertion and which assertions you share.
Check discovery before your agent calls out
The same registration protects your side when your agent is the caller. Before your agent sends credentials to the provider’s service, it can check what discovery told it against the registration. Agent2Agent (A2A), a protocol for agents collaborating across services, describes each service in an Agent Card and defines optional card signatures and caching guidance. A signature helps only when its signer is one you already approved for that service. Your client checks the card’s signer against the registration, then checks the endpoint in the card against the approved one.
The connection must then reach that endpoint. Transport Layer Security (TLS) service identity verification compares the server’s certificate with the service your client meant to contact. A redirect needs its own decision: may the new destination receive the credential? Cached cards need a rule too. A card signed last month keeps a valid signature after the provider moves the approved endpoint. Your client should accept a cached card only while it still matches the current registration.
To continue reading this article, please subscribe, it is free for all my subscribers.
Peace. Stay curious! End of transmission.
Fact-check appendix
The registration composition, disclosure rules and operating requirements are the author’s architectural synthesis. Source documents support the component properties below.
Statement: The helper’s documentation says the generated application does not enforce those requirements. | Source: Google Agent Development Kit, hosting-helper documentation in pinned source. Scope is this helper and its metadata declarations.
Statement: There, an identity provider (IdP) gives an identity assertion to an application, and the application decides whether to accept it. | Source: OpenID Foundation, OpenID Connect Core, authentication and relying-party roles, and OASIS Security Services Technical Committee, identity-provider and service-provider roles. The comparison covers the trust relationship only. Agent workloads can use non-interactive credentials.
Statement: To federate with another trust domain, the SPIFFE specification requires you to configure that foreign trust domain, its bundle endpoint and how to authenticate that endpoint. | Source: SPIFFE Federation, endpoint parameters and preservation of the domain/bundle association.
Statement: Or your own identity platform, if it supports token exchange, can validate the provider’s credential, apply your policy and issue a fresh token for your service. | Source: OAuth 2.0 Token Exchange, security token service and exchange processing. Availability and accepted token types depend on the platform and its policy.
Statement: Enterprise identity platforms can manage application registrations and service identities. | Source: Identity-platform documentation, application and service principal objects. The cited platform implements this through application registrations and tenant-local service principals. Agent/provider associations can use existing fields or extensions where supported, with application checks configured to enforce them.
Statement: A workload identity control plane assigns identities to running software based on registered properties of the workload, such as its namespace or service account. | Source: Workload registration documentation, registration entries and workload selectors. This supplies workload identity. Separate authentication of each agent object requires the runtime boundaries described in the body.
Statement: Store the link between that identity and the approved agent in a registry you already trust, such as an application registry or a directory accessed through the Lightweight Directory Access Protocol (LDAP), using existing fields or a schema extension. | Source: LDAP Directory Information Models, entries, attributes and schema. The proposed agent association requires suitable fields and administrator-controlled enrollment. Directory storage alone neither verifies the provider nor enforces the receiving application’s lookup.
Statement: A scoped identifier leaves the other fields of a signed assertion visible. | Source: Author’s architectural analysis of recipient-scoped references. OpenID Connect subject identifier types support the narrower correlation-reduction objective for End-User identities.
Statement: Agent2Agent (A2A), a protocol for agents collaborating across services, describes each service in an Agent Card and defines optional card signatures and caching guidance. | Source: A2A specification, discovery, signing and caching.
Statement: Transport Layer Security (TLS) service identity verification compares the server’s certificate with the service your client meant to contact. | Source: Service Identity in TLS, reference and presented identifier comparison.
Statement: If either can present that credential and write any agent name into the request, your service has no authenticated way to tell them apart. | Source: Author’s conditional attribution analysis, grounded in SPIFFE identity scope and interpretation. No exploitation result is claimed.
Statement: Demonstrating Proof of Possession (DPoP) binds a token to a key, and the caller signs a fresh proof with that key for each request. | Source: OAuth DPoP, proofs and token binding. The following client-authentication limit is stated in its introduction, and legitimate-signer misuse is covered in its untrusted-code discussion.
Statement: The verifier appraises that evidence against its policy and produces an attestation result. | Source: RATS Architecture, roles, trust relationships and appraisal.
Statement: It cannot tell you when each configuration property was measured, or whether that configuration was the one running during a later task. | Source: RATS Architecture, freshness methods and limitations. The preceding challenge claim assumes unpredictability, verified signed inclusion and comparison with the sent value.
Statement: A new workload certificate can remain verifiable under an already accepted issuer chain, even when the workload’s own key changes. | Source: SPIFFE identity and verifiable identity documents describe issuer-authenticated workload credentials. Federation key management separately covers distributing changes to issuer trust material. Explicitly pinned participant keys require their own binding updates.
Statement: Cached decisions stay acceptable only within the scope and maximum age you chose in advance. | Source: Author’s operating policy. OAuth Token Introspection, security considerations, documents stale-state exposure and cache tradeoffs. It sets no universal refresh interval.
Top 5 authoritative sources
SPIFFE Federation. The official federation specification defines the issuer-domain, key-source and distribution requirements grounding the trust setup.
A2A specification. The versioned protocol specification defines Agent Card discovery, optional signatures and caching behavior.
OAuth DPoP. The published token-binding specification distinguishes possession proof from client authentication and documents accessible-signer misuse.
RATS Architecture. The published attestation architecture defines evidence appraisal, trust relationships and freshness limits.
Workload registration documentation. The official registration guide makes the workload-properties-to-identity association concrete without implying an agent/provider identity standard.
P.S. How AI was used in the creation of this piece:
The idea is mine.
AI helps me brainstorm the argument’s spine and structure.
AI helps me with research, which I verify before anything goes into the article.
I write the full draft myself, over the course of several days.
I pass the draft through AI for an editing pass, using prompts I designed myself.