Tenant IAM is not open-web authority: The Open Authority Plane

Past the Perimeter: an Open Authority Plane for agents that work across organizations.

Your agents are about to leave the building.

They will call tools you do not host, hire specialists you do not employ, and spend budgets outside systems you administer. Your platform may also accept requests from agents whose operators have never logged into your identity provider.

Inside your organization, an agent has an owner, credentials, policies, and logs. The outside platform gets a request.

That platform has to decide whether the caller represents the claimed operator, whether its authority covers this action, and whether that authority is still valid. A familiar marketplace name cannot answer those questions. Neither can an internal directory entry the receiver cannot inspect.

Draw an arrow from “our agent” to “external service,” label it OAuth, and the architecture diagram looks finished.

Now ask the receiving team which operator it accepts, what the grant permits, and how quickly a revoked agent loses access. The arrow has no answers.

We call this the Perimeter Gap: the missing continuity between authority established inside one organization and evidence another organization can evaluate before accepting an agent’s action.

At HeadlessDomains.com, we propose an Open Authority Plane (OAP): a public, IdP-independent way to discover and verify the evidence behind an agent’s operator, authority boundaries, endpoints, payment context, and lifecycle.

Give every externally acting agent an authority surface another platform can inspect without becoming a member of the originating tenant. Let the receiving platform use that evidence to make its own decision.

OAP is an architectural proposal. Its test is whether an independent receiver can verify the evidence, enforce its own limits, and respond when authority changes. The protocols below supply building blocks; they do not constitute an adopted OAP standard.

The Agent Identity Stack maps the wider system. This article addresses the cross-organization acceptance contract: what evidence leaves one administrative domain, what another domain accepts, and where the resulting decision is enforced.

The boundary is trust, not the firewall

Modern identity systems already cross networks and organizational boundaries. Any argument for OAP has to start there.

SPIFFE Federation explicitly supports authenticating workloads across trust domains, including domains operated by different companies. OpenID Federation defines a way to establish trust through multilateral federations. OAuth has mechanisms for exchanging tokens and representing delegated actors. These are substantial building blocks. SPIFFE Federation, OpenID Federation 1.0, OAuth Token Exchange.

Start with what the receiver already knows.

A partner you have onboarded can recognize an issuer, apply an agreed policy, and map an identity into local permissions. A service your agent discovers five minutes before calling may have none of those arrangements. It needs a safe path from a public claim to an acceptable trust relationship.

“Without joining our IdP” means the receiver should not need an account in your tenant merely to inspect your agent’s public evidence. It does not mean the receiver must accept your issuer, skip onboarding, or grant access without a contract.

For some actions, an unknown operator should remain an unknown operator. The correct result is refusal.

This is why “your IdP ends at the firewall” is too crude a diagnosis. The boundary that matters is where another party becomes responsible for deciding what your agent can do.

There are also different identities inside the word agent:

An agent platform may fill several of these roles. That is not a reason to collapse them into one name. A valid platform signature does not, by itself, show that a customer authorized a purchase.

OAP should preserve those relationships across the boundary.

The two half-answers leave the receiver with work to do

A marketplace listing makes a service easier to find. Enterprise IAM makes an agent easier to govern under an organization’s policies. Neither, on its own, establishes the complete relationship an unfamiliar receiver needs.

A listing may contain a name, capabilities, reviews, and a payment address. It can also link to strong evidence. But the receiver must know which claims the marketplace verified, what the verification covered, and whether those claims remain current.

“Listed,” “account claimed,” “controls this key,” and “authorized for this transaction” describe different facts.

Enterprise IAM has a different starting point: an administrative authority and resources under its governance. Microsoft’s current documentation makes a specific boundary visible. Entra agent identities are single-tenant. Multitenant blueprints can create identities in other tenants, but those identities remain local to their respective tenants. That documented restriction should not be generalized into a claim that all Microsoft identity technology is incapable of federation. Microsoft Entra agent identities.

Ping’s cross-domain example combines delegated identity, detailed authorization requests, proof of possession, and a target authorization server that applies its own policy. It demonstrates why “Ping only works inside the building” is also an inadequate argument. The target’s acceptance rules remain part of the design. Ping cross-domain access.

CyberArk’s current product route leads to Palo Alto Networks’ Idira platform, which describes agent discovery, ownership context, privilege controls, and auditing. These controls belong in the architecture. An OAP proposal has to explain how externally useful evidence connects to them. Idira identity security.

A platform team therefore has two jobs: govern its own agents and make the evidence relevant to outside decisions available beyond its administrative boundary.

Buying a name handles neither job automatically. Buying IAM does not automatically finish the second.

What belongs in an Open Authority Plane

An Open Authority Plane makes agent authority inspectable across independently governed platforms. It connects public discovery to verifiable operator and delegation evidence, then defines how receivers evaluate that evidence under their own acceptance policies.

It complements the control systems that issue credentials and the enforcement systems that accept or reject actions.

“Public” describes the inspection entry point. It does not require publishing customer mandates, access tokens, internal hostnames, employee details, or transaction histories.

“IdP-independent” means receivers can discover and interpret the public surface without depending on one vendor’s tenant API. An implementation may still use that vendor’s credentials or federation mechanisms where the receiver supports them.

The plane needs five connected surfaces:

A published scope field says what someone claims or advertises. It does not issue a grant. A payment address says where value can go. It does not establish permission to send it.

The receiver needs to distinguish at least four states: a claim was found; its signature was checked; its issuer was accepted for that claim; and a particular action was authorized. Flattening those states into a green “verified” badge throws away the information this architecture exists to preserve.

Some evidence will be public; customer-specific grants remain protected. The useful property is a predictable path between discovery, proof, and a receiver’s decision. Our public inspection layer guide covers what operators publish. OAP adds the acceptance rules that give the evidence an operational meaning across organizations.

Where existing protocols fit

OAP should reuse mechanisms that already have implementers, security analysis, and operational experience. Build the connections using established formats wherever they fit.

The standards and products below cover different portions of the problem. Several already reach beyond identity into authorization and governance.

OAuth and MCP already carry real authority

MCP authorization defines how protected servers advertise their authorization servers and how clients obtain and use resource access tokens. Its Enterprise-Managed Authorization extension adds an ID-JAG exchange involving an enterprise IdP and the MCP server’s authorization server. Calling this “just a login” would miss the point. MCP authorization, Enterprise-Managed Authorization.

OAP’s proposed contribution is the surrounding continuity: how a receiver connects this token and resource interaction to the responsible operator, stable agent identity, relevant mandate, and current lifecycle evidence.

OAuth Token Exchange supplies delegation machinery; Rich Authorization Requests supplies structured authorization details. The deployment still needs agreed semantics and enforcement. A receiver should not infer an unlimited delegation chain from the presence of an act claim. RFC 8693, RFC 9396.

An Agent Card can be signed and access-controlled

A2A cards can describe interfaces and security requirements. The specification permits signed cards, and authenticated extended cards can reveal information unavailable in a public card. The server remains responsible for authorizing requests under its own policies. A2A specification.

A card is therefore a useful OAP input. The remaining questions concern the signer’s authority, the relationship between card and live workload, the meaning of claimed permissions, and the currency of the evidence.

A signed document from an unaccepted issuer is still evidence from an unaccepted issuer.

Public credentials already separate verification from trust

W3C Verifiable Credentials explicitly leaves verifiers responsible for deciding which issuers and claims satisfy their requirements. DIDs can supply verification methods and service references, but identifier control and a business’s authority are different questions. Verifiable Credentials Data Model, DID Core.

An OAP implementation can use these standards. It does not require every agent to adopt a DID, and using one does not eliminate the receiver’s trust policy.

Payment protocols are already doing identity work

Visa’s Trusted Agent Protocol describes signed information for agent recognition and commerce under payment-scheme trust arrangements. AP2 goes further than a payment receipt: its current specification defines checkout and payment mandates, while its authorization framework covers delegation and verification. Visa TAP specification, AP2 specification, AP2 authorization.

MPP’s current identity documentation separates request attestation from payment credentials. It supports Web Bot Auth and TAP profiles and describes proving control of a credential’s key, including identity-only flows. Its documentation explicitly tells implementers to apply their own policy after verification. MPP identity.

x402 documents HTTP payment challenge and response flows. Mastercard’s Agent Pay for Machines announcement describes credentialing, controls, and settlement for machine commerce. These systems should be evaluated on what they actually do, rather than dismissed as money movement with no identity model. x402 HTTP 402, Mastercard Agent Pay for Machines.

A single workflow can cross several of these arrangements. Its evidence needs to stay connected as it does. OAP is our proposal for making that connection explicit. It is not evidence that these providers endorse HeadlessDomains.com or accept its records.

Put the decision on the receiving side

A useful architecture has to identify who can say no.

The following is a reference design for OAP, not a deployed HeadlessDomains.com integration:

Originating organization
  IAM / workload identity / delegation / budget controls
                         |
               credentials and grants
                         v
                    Agent runtime
                         |
                request + bound proof
                         v
Receiving platform
  Verify evidence -> Apply local policy -> Enforce -> Record outcome
         ^
         |
  OAP discovery and evidence
  identity / operator / endpoints / authority references / lifecycle
         |
  accepted issuers, key sources, status services, payment evidence

The public plane helps the receiver gather evidence. It cannot force the receiver to accept an operator or override the policy protecting a resource.

Consider an illustrative workflow. A research agent has a $20 budget to buy one analysis from an external specialist. The specialist may use a separate data provider. The amounts and services here are hypothetical.

The buyer’s agent discovers the specialist through a marketplace. Before hiring it, the buyer’s platform resolves the specialist’s identity, checks the operator evidence it accepts, and binds the proposed service endpoint and payee to that identity.

The specialist performs the corresponding checks on the buyer. A legitimate seller can still receive an unauthorized request.

The grant identifies the buyer’s principal and the runtime actor. It restricts the action to the agreed analysis, names the intended recipient, expires at a stated time, and limits spending. If the quote is $18, the payment step must bind that quote to the correct payee and task.

Now the specialist wants to spend $5 at a data provider. That authority does not follow automatically from the buyer’s $20 budget. The contract and delegation policy must establish whether subcontracting is permitted, who pays for it, and which data can be disclosed.

If the specialist pays from its own account, that is a separate grant under its own principal. If the buyer authorizes downstream spending, the receiver must verify the permitted delegation and reserve spending against the shared budget. Copying a $20 ceiling into several child tokens would allow the combined spend to exceed $20.

At every boundary, the receiving party decides under its own policy.

A usable record of the transaction connects the task, the applicable grant, the authenticated actor, the quote and payee, the payment result, and the delivered outcome. A payment receipt alone cannot show that the specialist returned the promised analysis. Keep protocol-specific payment design in the separate x402, AP2, and MPP comparison; the OAP question is which actor and authority each piece of transaction evidence belongs to.

A receiver needs an explicit acceptance contract

For a consequential action, the reference design should require answers to these questions:

1. Which identity is being asserted, and which operator or principal stands behind it?
2. Which issuers may establish each relevant claim?
3. What binds the live request to the verified identity and credential?
4. Does the grant cover this action, resource, recipient, time, and delegation depth?
5. Are the endpoint and payment destination the ones the accepted evidence identifies?
6. Is the evidence current enough for this action?
7. Does local policy allow the action now, including budget and required approvals?
8. What evidence will be retained so another team can reconstruct the decision?

These checks belong in deterministic code and policy enforcement points. The model may propose an action and explain its purpose. It should not decide whether its own cryptographic proof or spending authority is valid.

AP2 makes a related requirement explicit: validation and processing required of protocol roles must happen in deterministic code. AP2 verification requirements.

The receiver can return more than allow or deny. It may require a trusted issuer, a narrower grant, an operator review, or a different payment method. Those outcomes make the boundary usable without pretending every stranger is already trusted.

Write the acceptance profile before adding another manifest

A receiver should publish the evidence classes and protocol profiles it supports, while keeping sensitive local rules private. The caller can then determine whether it has a supported route to acceptance before attempting consequential work.

For the research-purchase example, an illustrative acceptance profile looks like this:

These are proposed design rules, not an OAP schema or production configuration. A deployed profile must name exact credential formats, algorithms, issuer policies, action definitions, freshness limits, and error behavior. Values such as “fresh” and “trusted” are not sufficient configuration.

Version the profile and bind the decision record to that version. A peer that does not support the required semantics should receive an explicit refusal or onboarding path. It should never discover halfway through settlement that the two platforms meant different things by “authorized.”

The Agent Handshake guide covers a caller’s checks before handing work away. This profile supplies the receiving platform’s contract for accepting it.

Delegation must narrow authority as work spreads

An agent that hires another agent creates a new authorization problem.

The child needs authority to perform its part of the task. It should not inherit every permission held by the parent. Nor should the receiver have to reconstruct the entire chain from conversational prose.

A delegation profile needs precise rules for resources, actions, audiences, expiry, spending, further delegation, and the identities retained at each hop. Each child grant must stay within the authority its issuer is entitled to delegate.

Expiry and scope are only part of this. A parent allowed to spend $20 cannot safely issue ten independently spendable $20 grants. Shared limits require allocation or accounting at an enforcement point that can prevent concurrent overspending.

OAuth provides useful primitives, but multi-hop semantics remain an active area of work. An August 27, 2026 Internet-Draft proposes verifiable, attenuated agent delegation chains. An August 30 draft profiles delegated agent authorization using existing OAuth mechanisms. Both are work in progress, not adopted IETF standards. Agent delegation chain draft, Delegated agent authorization draft.

Advertise the delegation profile a receiver can actually validate. Unknown semantics should trigger refusal or review, rather than optimistic interpretation.

The architecture should also preserve the principal separately from intermediate actors. If a user authorized an agent to obtain an analysis, an audit should not erase that user’s role or imply the user personally made every downstream request.

Revocation has to reach the next decision

Deleting an agent from your directory does not recall a token cached elsewhere, undo a completed payment, or stop a job running under a separate provider’s credentials.

Revocation is a distributed-systems problem as much as an identity problem.

OAuth token revocation defines an invalidation mechanism and acknowledges propagation delays. Token introspection lets a protected resource ask about token state, but caching those answers trades freshness for performance. RFC 7009, RFC 7662.

An OAP design needs to make that tradeoff visible.

Start by separating the things being revoked. An operator binding, a signing key, a runtime instance, a task grant, a payment credential, and an entire service may have different lifecycles. One “active” flag cannot reliably describe all of them.

Then define what every receiver does with a status change. A public record saying “retired” only has an effect if the enforcement point checks and honors it. Event delivery can reduce delay, but receivers still need rules for missed events, old signatures, unavailable status services, and cached evidence.

For offline validation, short credential lifetimes can bound some exposure. They do not create instant revocation. Where the required stop time is shorter than the remaining credential lifetime, the architecture needs an additional online check, push mechanism, or enforceable local kill switch.

A practical acceptance criterion is a measured maximum age for evidence at the moment of action. Teams should measure the elapsed time between revoking a grant at its authoritative source and rejecting it at each downstream enforcement point.

Long-running jobs need separate treatment. Stopping new requests may leave an accepted task running for another hour. Define whether revocation cancels that job, blocks its next tool call, stops additional spending, or only prevents future work. Each behavior requires provider support.

The offboarding guide covers retiring the whole service. Here, the test is whether each independent receiver stops honoring the affected authority within its agreed window.

Also plan for ownership changes. If a name is transferred or re-registered, a new holder should not silently inherit an old operator’s approvals. Bind acceptance to the relevant operator, issuer, keys, and ownership period; force review when those relationships change.

A stable name is useful precisely because the things behind it change. The verifier must be able to tell which changes preserve an accepted relationship.

A public authority surface creates its own attack surface

Publishing more metadata helps attackers too. The plane needs the same threat modeling as the services that consume it.

Proof of possession can reduce the value of a stolen token. OAuth’s security guidance describes sender-constrained and audience-restricted tokens; DPoP supplies an application-level proof mechanism. Neither prevents misuse by an attacker who controls the authorized runtime and its signing capability. OAuth Security BCP, DPoP.

HTTP Message Signatures can bind covered message components to a key. The application still has to choose the right components, establish trust in that key, and handle replay. A signature over a request is evidence about that request, not proof that its intended outcome is safe. HTTP Message Signatures.

Discovery also needs careful handling. MPP’s identity documentation, for example, warns against fetching caller-provided key-directory locations before applying a trust policy. That is a useful constraint for any OAP resolver or verifier. MPP identity security guidance.

Privacy imposes a second limit. Publish the minimum necessary entry point, then disclose sensitive evidence under appropriate access controls. A public endpoint for every credential can reveal who is verifying whom. W3C’s Bitstring Status List discusses that correlation risk and provides a status mechanism designed to reduce it. Bitstring Status List.

Even a well-designed OAP cannot guarantee model behavior, service quality, solvency, or contractual performance. It supplies evidence and control hooks that help a receiver decide what exposure to accept.

Pilot the acceptance contract on one external workflow

A team does not have to replace its IAM to test this architecture.

Begin with one external workflow and one receiver willing to implement a shared acceptance profile. Document the action, principal, agent service, runtime, data involved, spending limits, and stop conditions.

Implement the contract through the systems you already operate.

Publish the inspection surface. Expose a stable identifier and current service metadata. Identify which fields are self-asserted, issuer-backed, or only available to authorized counterparties. Reference existing Agent Cards, OAuth metadata, and other appropriate documents rather than copying them into conflicting records.

Bind the live workload. Establish how the receiver connects a presented credential and request proof to the service identity and responsible operator. Use credential types and issuers the receiver already accepts where possible.

Make action authority explicit. Define the grant profile, action vocabulary, intended resources, delegation rules, and any payment mandate. Resolve ambiguous semantics before opening the route.

Enforce at both ends. The origin controls what its agent can attempt, including data egress and spending. The receiver independently controls what it will accept. A public record does not replace either enforcement point.

Exercise failure. Revoke a grant during a job, rotate a key, change a payee, interrupt the status service, and replay a request. Verify that the result matches the written acceptance policy.

An OAP pilot should produce evidence a staff engineer can review:

Measure decision latency, evidence availability, stale acceptance, revocation propagation, and review frequency. Keep those measurements separate from claims about task accuracy or business value.

The pilot passes when the receiving team can explain an acceptance or refusal, reproduce its evidence checks, and demonstrate the agreed stop behavior without access to your internal dashboard.

What HeadlessDomains.com contributes today

HeadlessDomains.com provides parts of the public identity and discovery substrate this architecture needs.

Its documented resolver, GET /api/v1/resolve/{domain_name}, is public and read-only. The current documentation describes a versioned response containing lifecycle information, public identity, capabilities, validated action descriptions, manifest and skill links, service discovery, and separately labeled trust evidence. It also documents distinct conditions for missing, expired, suspended, and unavailable domains. HeadlessDomains.com developer instructions.

The OpenAPI contract explicitly describes that resolver as discovery. It does not authorize or proxy execution. The Action Card schema provides a way to describe provider invocation requirements; schema validation is not independent verification of a provider’s honesty or permission to act. HeadlessDomains.com OpenAPI, Action Card schema.

The documented human-claim flow binds an agent account to an operator account for management. That account relationship should not be represented as proof of a legal organization’s identity, a user’s consent to a transaction, or another platform’s acceptance. Operator claim workflow.

Headless namespaces are anchored on Handshake, with infrastructure through Headless Domains and SkyInclude for machine use. Agents can use the documented API and command-line workflows; their usefulness does not depend on conventional browsers resolving those names natively. The name supplies a continuing reference, while the service and authority evidence can change behind it. HeadlessDomains.com technical index.

The current OpenAPI documentation also describes revocation of Headless Domains API keys and distinguishes credentials that must be revoked at their own issuer. That is a specific lifecycle capability. It should not be described as universal revocation across every downstream service. API key revocation contract.

For a complete OAP deployment, implementers still need accepted issuer policies, cryptographic operator and workload bindings where required, precise delegation semantics, receiver enforcement, payment integration, and tested status propagation. Those requirements belong in the integration plan; the current public documentation does not establish a complete OAP implementation.

HeadlessDomains.com can provide a maintained starting point for that integration: a resolvable name and records that independent verifiers can inspect. The next step is connecting them to the receiver’s actual controls.

A namespace can be one substrate for that work. An ordinary HTTPS identifier or a suitable DID can also participate in an OAP design. The architecture earns adoption through interoperable verification, not an exclusive dependency on a particular suffix.

The industry is building toward this boundary

The broader direction is already visible.

NIST’s software and AI agent identity work asks how existing identity standards can support authorization, auditing, and accountability for agents. OpenID’s AuthZEN work includes draft profiles for acquiring authorization prerequisites and mapping MCP tool information into authorization decisions. NIST concept-paper announcement, AuthZEN working-group drafts.

MCP’s current roadmap explicitly includes agent identity and delegation, with work involving workload federation, ID-JAG, proof of possession, and token exchange. A roadmap describes direction; it does not mean every listed mechanism is already part of the stable protocol. MCP roadmap.

Cloudflare’s August 2026 account of an open agentic internet connects identity, discovery, invocation, and payment, while allowing domain owners to choose their own providers. OAP belongs in that conversation as a proposal for making authority evidence coherent across independently operated systems. Cloudflare’s open agentic internet.

Platform teams now have enough building blocks to make progress. Someone still has to own the connections between them, including the decisions that sit outside any one protocol.

Before the next agent leaves your perimeter

Take one agent you expect another organization to hire, call, or pay.

Give that organization only the public entry point and the evidence your protocol permits it to receive. Then ask its engineers to establish the operator, verify the live actor, evaluate a bounded grant, bind the payment destination, and observe a revocation.

Every answer that depends on “ask someone in our tenant” identifies work still hidden behind the perimeter.

The promise of an Open Authority Plane is authority evidence that remains inspectable after egress, with the receiving platform retaining the right to refuse. Put it in the architecture review and test it at the receiving boundary.

For HeadlessDomains.com, the next conversation should start with that review: the external action, the receiver’s acceptance policy, and the evidence needed to support it.

Inspect the HeadlessDomains.com machine interface and evaluate it against your first external-agent workflow.