Identity is not authority: what IAM leaves open for agents

Key points

A valid identity shows who acts, not what is allowed.
A signature, a login or a known vendor are no permission for a specific action.
Authority is always concrete: action, principal, scope and point in time.
KYA keeps both questions visibly apart in the certificate, so no false sense of security arises.

What IAM answers

A good identity system knows which agent signs in, which key it presents and which interfaces it may access. Modern approaches give agents their own workload identities, short-lived tokens and narrowly cut permissions. That is necessary, but it answers a different question.

What IAM leaves open

An access right to the payment interface does not say whether this one payment of CHF 80 to this one counterparty was allowed today. Nor does it say on whose behalf the agent triggered it, whether that instruction still holds and how to prove this to an auditor three months later. Permissions describe possibilities; mandates describe authorizations.

Three common misconceptions

“The agent is authenticated, so the action is legitimate.” Authentication proves origin, not permissibility.
“The scopes limit the damage.” Scopes limit interfaces, not amounts, counterparties or frequencies.
“The logs are proof enough.” Your own system's logs cannot be verified independently by third parties and can be changed afterwards.

What closes the gap

Three building blocks: a signed mandate with scope and revocation, a verifier that checks every action against the mandate beforehand and decides fail-closed, and a receipt chain that records the result immutably. IAM remains the foundation: it provides the identity the mandate is bound to.

How to check the difference

In the verification model of KYA, identity and authority are separate checks. “Agent and principal” checks the binding, “Scope of the action” the permission. Evidence can pass the first and fail the second. If you want to secure your own agents this way, Mandact implements the three building blocks.

Three typical confusions

Signature equals permission: a valid signature following Web Bot Auth shows whose agent is asking. It says nothing about what it may do.
Login equals instruction: an agent working with its user's credentials inherits all rights of the account. Which of them it should use for this task remains open.
Known vendor equals permitted action: even the agent of a reputable vendor can make mistakes or be manipulated. Trust in the vendor does not replace checking the action.

What authority means in concrete terms

Authority is always concrete: a specific action, for a specific principal, to a specific extent, at a specific time. A mandate records these limits, a decision confirms before execution that the specific action fits, and a receipt shows afterwards what happened.

If one of these elements is missing, a gap remains. KYA reports it in the certificate: the checks for mandate validity, scope of action and execution binding each have their own status.

Identity and authority in the certificate

KYA's certificate keeps both questions visibly apart. Four fields show whether authenticity, identity and instruction, authority and proof are established. The Web Bot Auth example on the verification page shows the typical case: authenticity and identity are proven, authority is absent, and the verdict is indeterminate.

This separation is deliberate. A result that mixed identity and authority would lull verifying parties into a false sense of security.

What this means for architecture

Systems that admit agents need two separate checks. The first asks whose agent is asking and relies on signatures and keys. The second asks whether the specific action is allowed and relies on mandate, decision and revocation status. If both are mixed into a single role or a single token, gaps appear: whoever is authenticated is then often allowed more than they should be. Clean architectures keep both checks apart and record the result of each one.

Frequently asked questions

Why is a valid identity not enough for an action?

Because identity only shows who is acting. Whether the specific action was allowed depends on the limits set by the principal, and only a mandate proves those limits.

Can an agent prove identity and authority together?

Yes. A mandate in the SD-JWT VC format contains the agent's key and the limits of its authority. Together with the key binding JWT, it proves both in one piece of evidence.

What does KYA show if only identity is proven?

The verdict is indeterminate, and the certificate shows authenticity and identity as proven and authority as absent.

Is an API key proof of identity or of authority?

Rather an access means. It shows that someone holds the key and grants the rights of the related account, without distinguishing between tasks.

How does an agent prove its authority to a website?

By presenting a mandate or a signed purchase intent alongside the signed request. The website then checks both: whose agent is asking and whether the action is within the limits.

Does the separation also apply to internal agents?

Yes. An agent inside one's own company should also receive only the rights a task requires, and its actions should be checked against these limits.

What is the most common mistake when admitting agents?

Letting agents work with their users' credentials. The agent then inherits all rights of the account, and afterwards it is impossible to distinguish what the user did and what their agent did.

Sources

RFC 9421: HTTP Message Signatures: https://www.rfc-editor.org/rfc/rfc9421
NIST: Least Privilege: https://csrc.nist.gov/glossary/term/least_privilege