Platform layer — AI & LLM
Every agent action: identified, entitled, logged.
MCP lets an AI agent reach tools and data. It does not decide whether that agent is entitled to a specific dataset — or leave evidence either way. This layer adds credential checks at the MCP boundary and records every authorization decision. Available for scoped rollout with partners and enterprise platform teams.
The authorization gap in agent stacks
Agents inherit too much
Most agents run on a service account or a broad OAuth scope. One agent, one key, all the data. The moment the agent misbehaves — or is manipulated through its inputs — that whole scope is exposed.
No per-agent identity
When ten agents share one credential, no log can tell you which agent did what. Attribution ends at "the integration did it" — which is exactly where an incident review, a customer dispute or an audit starts.
No evidence across organisations
OAuth tokens work inside one trust domain. The hard cases are cross-organisational: a partner’s agent reaching your data, your agent reaching a supplier’s API. That requires verifiable identity and recorded rights both sides can check — and evidence both sides can keep.
“Doesn't MCP already have authorization?”
Partly — and we'll be precise about it. The MCP specification includes OAuth-based authorization, and it does its job: it lets a user grant a client access to a server. What it does not express is everything an organisation needs once agents act at scale: which specific datasets this agent may use, on whose behalf, under which inter-organisational agreement, and what evidence remains afterwards.
Our layer does not replace MCP's OAuth flow — it sits above it. The credential carries the agent's identity and its recorded data rights; the authorization layer evaluates them per call and retains the decision. OAuth answers “may this client connect?”. This answers “may this agent use this data, and can you prove it later?”
How it works
Agent gets a verifiable credential
Via OID4VCI, each AI agent receives a verifiable credential that carries its identity and its assigned data rights. SD-JWT allows selective disclosure of those rights per call.
Credential is presented at the MCP boundary
When the agent calls an MCP server, the authorization layer validates the credential, checks the rights, and either allows, scopes or denies the call.
Every action is auditable
Every credential issuance, presentation and authorization decision is logged. This is the audit trail your DPO and your compliance officer need.
API keys and scopes vs. verifiable credentials
| Keys & OAuth scopes | Credential-based authorization | |
|---|---|---|
| Identity | Shared service account or client id | Verifiable credential per agent |
| Rights | Coarse scopes, set once at integration time | Data-level rights, recorded in a registry, changeable without re-integration |
| Cross-organisation | Each party runs its own token silo | Both parties verify against the same trust framework |
| Revocation | Rotate the key, break every consumer | Revoke one agent’s credential, the rest keep working |
| Evidence | Server logs, if someone kept them | Signed decisions, retained per issuance, presentation and call |
Where this sits in the AI Act timeline
The AI Act phases in: general-purpose AI rules apply since August 2025, the Article 50 transparency obligations since August 2026, and the high-risk obligations — logging, human oversight, deployer accountability — from December 2027. Those obligations assume you can answer one question per agent action: who did what, with which rights, decided by whom.
This layer provides that groundwork: per-agent identity, scoped rights, and a retained record of every authorization decision. To be precise about the claim — an authorization layer does not make an AI system AI Act-compliant, and no vendor can sell you compliance as a feature. It gives your compliance and audit teams the evidence the Act's accountability obligations are built on.
Standards used
W3C Verifiable Credentials
The open credential model at the core of the stack.
OID4VCI
OpenID for Verifiable Credential Issuance.
DCP
Decentralized Claims Protocol — issuance and presentation for data-space participants.
SD-JWT
Privacy-preserving, selectively disclosable credentials.
EUDI Wallet ARF
Aligned with the European Digital Identity Wallet reference architecture.
iSHARE v3
European trust framework for data spaces — Protium is certified on two roles.
MCP-compatible
Authorization layer for the Model Context Protocol ecosystem.
EU Data Act
Applies since 12 September 2025 — our stack makes its data-access obligations operational.
Integration patterns
For enterprises deploying internal AI agents
Wraps your MCP servers and LLM platforms with credential-based authorization. Integrates with your IAM.
For platform teams exposing data to partner agents
Issue credentials to partner AI agents. Govern what they can access. Provide audit trails to partners and regulators.
For data spaces with AI participants
AI agents become first-class participants in the data space — with identity, rights and consent, just like human participants and partner systems.