The employee left. The agent did not.
Credentials and delegations survive offboarding.
The authority plane for AI agents
Access is not authority.
Your agent's identity, connection and token are all valid. None of that proves your organisation still authorises the exact action it is about to take.
Specified in the product contract
- AuthZEN-compatible policy consultation
- Ed25519 detached receipt signatures
- SHA-256 hash-chained evidence
- Independent receipt verifier
- Signed approval-provider callbacks
How it works
Every action stops at a checkpoint.
Delegrity sits between your agents and the systems they change. It consults the controls you already run, decides on the exact action, and returns signed evidence of what happened.
What Delegrity checks
Four checks between a request and its evidence.
For developers
One governed endpoint. A decision, not a pretend success.
An agent submits a proposal to POST /runtime/tool-requests. What comes back is an authority decision; execution stays NOT_DISPATCHED.
- Idempotency-Key must equal request_id, so a retry is a replay, never a second action.
- Principal and mandate are resolved server-side; the request cannot choose them.
REST, MCP, A2A and agent framework SDK wrapper request forms are registered and reach one governed endpoint, POST /runtime/tool-requests, for governed tools such as update_supplier_bank_account. Registered is not connected: there is no standalone MCP or A2A listener, and no live framework or provider connectivity is claimed.
RequestsubmitPublicAgentToolRequest
POST /runtime/tool-requests
Authorization: Bearer <workload token>
Idempotency-Key: req-7f2a91c4
Content-Type: application/json
{
"request_id": "req-7f2a91c4",
"agent": {
"agent_id": "00000000-0000-4000-8000-00000000a9e7",
"session_id": "00000000-0000-4000-8000-0000000051c2"
},
"tool": {
"name": "update_supplier_bank_account",
"arguments": {
"supplier_id": "sup-00482",
"account_number": "0000 0000 9930",
"country_code": "GB",
"routing_code": "00-00-00",
"beneficiary_name": "Example Supplies Ltd",
"reason": "Supplier emailed new bank details"
}
},
"context": {
"instruction": "Update the supplier's bank account from the latest email",
"timestamp": "2026-09-29T10:15:00Z"
}
}Response201 · publicToolResponse
{
"request_id": "req-7f2a91c4",
"decision": "AWAITING_APPROVAL",
"reason": {
"code": "APPROVAL_REQUIRED",
"message": "Beneficiary change needs a human decision on this digest."
},
"execution": {
"status": "NOT_DISPATCHED",
"connector_invoked": false
},
"correlation_id": "corr-3c9d0e12",
"replayed": false
}AWAITING_APPROVAL is a decision, not a result: nothing is dispatched until a person approves this exact digest and the recheck passes.
For your security review
What you can check today, and what we don't claim.
Each capability declares its mode: Observed, Assisted, Enforced or Hybrid. We say Enforced only where a non-bypassable enforcement point is proven.
Demonstrable in a live walkthrough
- Principal, agent, mandate and capability as versioned objects.
- Requested, approved and execution snapshots compared field by field.
- A changed field or mandate epoch voiding a prior approval.
- Single-use execution authority bound to one exact action.
Not claimed yet
- No independent certification yet. Our testing is our own.
- No production customer evidence yet, so no enterprise-ready claim.
- No named vendor connected, and none implied by this page.
- An unsigned receipt is shown as unsigned, never implied.
Questions
Asked before every demo.
What does working with you look like, and what does it cost?
We start as a design partner on one consequential workflow, at no platform commitment. A pilot then runs one protected capability in your environment, scoped and priced with you. There is no self-serve tier or per-seat menu yet.
Does Delegrity replace our identity provider, policy engine or approval tool?
No. It works beside them. Delegrity consults your policy engine through AuthZEN-compatible policy consultation, binds your approvals to the exact action, and keeps your identity provider as the source of who an agent is.
Which agents can send requests to it?
REST, MCP, A2A and agent framework SDK wrapper request forms are registered and reach one governed endpoint, POST /runtime/tool-requests, for governed tools such as update_supplier_bank_account. Registered is not connected: there is no standalone MCP or A2A listener, and no live framework or provider connectivity is claimed.
Where does it run?
Hosting and credential custody are agreed per deployment. A customer-hosted enforcement bridge is part of the enterprise scope, so execution credentials can stay in your environment.
What evidence do we get for each action?
An evidence chain hashed with SHA-256 and a receipt with an Ed25519 detached signature, checkable by an independent verifier. Completeness is shown explicitly, and an unsigned receipt is labelled unsigned.
Is it ready for production?
Not yet claimed. Delegrity is at design-partner stage, with no production customer evidence and no independent certification so far. We would rather say so than overclaim.
Request a demo
Bring one action that can move money.
- We reply by email to arrange a 45-minute session.
- Together we map one protected action, its owner and its limits.
- You get an authority map and an honest next-step recommendation.