Each AI agent you register has an owner, a ceiling and a kill switch.
Pramaan gives each AI agent a sign-in identity of its own, with a named human owner, a ceiling on what it may do and a kill switch. It can never hold more than its ceiling allows, and it can be switched off. The whole path ships off.
Owner, ceiling, kill switch
Owner
Each agent has exactly one human owner. Deactivating or deleting that person stops the agent's next token request too.
Ceiling
An administrator sets the widest set of scopes an agent may ever hold. A token request gets only the scopes that fall inside that ceiling.
Kill switch
Disabling an agent stops new tokens; tokens already issued stay valid until they expire.
How an agent gets a token
The agent signs in with its id, its secret and a proof made with its own key, and the token it receives is bound to that key, whatever the deployment-wide binding setting. Also, by default its key must belong to a device the owner enrolled, so a leaked secret alone does not mint a token elsewhere; an administrator can relax that for agents on machines nobody enrolled.
It receives access tokens only, with no ID token and no token to renew them, valid 300 seconds by default. When a token runs out, the agent asks for a new one.
A decision for each tool call
With its own switch on, an agent asks the broker before it uses a tool: your access rules decide each tool call, and a tool no rule allows is refused. The agent's bound token needs a proof from its key there as well.
Receipts you can check without us
With receipts switched on, the broker hands the agent a signed receipt when it issues a token and when it decides a tool call. Receipts verify offline against the public key: an owner, an auditor or the tool's operator checks one with the broker's published keys; nothing about the receipt itself is asked of the broker.
For your engineers
Technical detail: tokens, the decision route and receipts
The agent's proof is a DPoP proof, and its token is bound to the DPoP key whatever the deployment-wide DPoP setting. It receives access tokens only, with no ID token and no refresh token. Per-tool decisions are asked at POST /mcp/authorize, which needs a DPoP proof too. To check a receipt yourself:
- The receipt is a compact JWS signed with the same key that signs the broker's ID tokens; the algorithm is ES256.
- To check one, take the broker's public keys from /jwks, fetched once or kept from earlier.
- Finally, verify the signature, then check the receipt's rcpt claim, which marks it as an action receipt rather than another token the same key signed.
Questions
Does disabling an agent stop it at once?
It stops new tokens; tokens already issued stay valid until they expire, 300 seconds by default.
Can an agent renew its own token?
No. It receives access tokens only, with no ID token and no token to renew them, and asks for a new token when one runs out.
Is a leaked agent secret enough to get a token?
By default, no: by default its key must belong to a device the owner enrolled, so the secret alone does not mint a token on another machine; an administrator can relax that for agents on machines nobody enrolled.
Does the tool traffic pass through Pramaan?
No: the broker returns a decision; the tool call itself does not pass through it.
Is any of this on by default?
No. Agent identity and per-tool decisions each ship off, each behind its own switch; the chips on this page name them.
Talk to us, or try it first
-
Book a walkthrough
Against your own apps, not slides.
-
Run the lab
It uses a demonstration account; none of your data is involved.
-
See pricing
Published floors, named-user bands and what every tier includes.