Verifiable permissions for AI agents across organisations
Every AI agent given its own decentralised identity and credential-based permissions, checked by zero-knowledge proof at an on-chain validator and logged. Agents from other organisations admitted the same way. Tools reached over MCP.
A global technology company wanted to give AI agents real work inside its enterprise systems: read evidence files, query the ERP, pull a cap table, fetch documents. The question was not whether an agent could call the tool. It was who the agent was, what it was allowed to touch, who said so, and what record remained afterwards. Gateway built a pilot in which every agent carries a decentralised identity and a set of credentials, proves its permissions with a zero-knowledge proof at each request, and leaves an on-chain record of the decision. Agents from other organisations are admitted the same way, without merging directories.
Six things the pilot had to get right
An identity for every agent
- Each agent is created against a person or service already known to the enterprise directory. Only an identity holding an admin credential can create one.
- The agent receives its own iden3 identity: a key pair, a claims tree and a state anchored on the chain.
- Public and private agent roles are credentials too, not flags in a database.
Permissions as credentials
- Access to a system is a credential issued to the agent’s identity by an authorised issuer, naming the system it covers.
- Nothing is granted by configuration on the tool side. The tool server holds no list of agents.
- Credentials are revocable through a state update, and the validator checks against current state.
Access by proof
- At each request the agent generates a zero-knowledge query proof that it holds the required credential.
- A validator contract verifies the proof on the chain before the request proceeds.
- The proof reveals the permission, not the credential or the agent’s other claims.
A record that outlives the session
- Every verified request is logged by the contract as an event.
- Requests without a valid credential are logged as attempts, with the agent and the system named.
- The log is indexed, so an operator can see what an agent asked for and when.
Escalation instead of silent failure
- A denied request can raise an approval request on the contract.
- A designated approver decides, and the decision lands in the same log.
- The pattern extends to multi-party approval where more than one person must consent.
Agents from other organisations
- Because the agent’s identity is a DID rather than a row in one company’s directory, a second organisation can issue it a permission credential for its own systems.
- The validator verifies that credential against the issuer’s state, not against a shared user list.
- Two organisations, one agent, no merged directory.
What each request produced
Systems are numbered in the pilot rather than named. A permission credential covers one system. An agent holding none for a system cannot construct a proof for it, so the refusal is structural, not a policy lookup.
Checked end to end
- Agent creation refused without an admin role proof
- Access allowed only with a proof of the matching permission credential
- Denied attempts written to the contract with agent and system
- Approval requested and recorded on the contract for a denied request
- Credential issued by the customer to an agent created elsewhere, and accepted
- Executor agents proving their own permissions, not the orchestrator’s
Six parts, and what each one provides
Identity service
- Creates agent identities against the enterprise directory
- Issues identity, role and permission credentials as iden3 claims
- Keeps claims trees and state, and publishes state to the chain
Prover
- Generates authentication, credential-query and state-transition proofs
- Runs as a separate service, so keys and circuits stay out of the agent runtime
Access validator contract
- Verifies query proofs against the iden3 state contract
- Logs verified requests and denied attempts as events
- Holds the approval path: request, approver, decision
Agent manager
- Creates agents with instructions and a public or private role, gated by a role proof
- Runs conversations and threads for each agent
MCP tool servers
- Evidence store: list and read files
- ERP: overview and detail queries
- Finance: cap table and runway
- Documents: fetch
Orchestration
- A planning agent splits a request into partial requests
- Executor agents run them against their own tools and identities
- A synthesis agent assembles the summary
What this record does and does not claim
The customer is a global technology company and is not named. The pilot ran against the customer’s systems through MCP servers and the customer’s enterprise identity directory.
It is a scoped validation of the identity and permissioning model, not a production deployment. No throughput, cost or scale figures are published from it.
The model went on to become Gateway’s Enterprise AI Firewall.