AI agent governance: permissions, identity and audit
Governing AI agents means deciding, before they act, who can use which tool, with what identity and within what limits, and keeping a record of everything they do. Today each MCP server handles this its own way, or not at all. It’s worth bringing it into a single point before someone holds you to account.
What changes when an AI agent uses real tools?
An assistant that only chats can be wrong about what it says. An agent with tools can be wrong about what it does: query a database it shouldn’t, open a hundred tickets, change a configuration or delete a record.
In critical operations the difference is plain: an agent that checks the state of the network saves you time; one that can also change a setpoint or close a valve calls for a different conversation.
More and more, those tools arrive over MCP (Model Context Protocol), an open standard that AI assistants and agents use to work with external tools: querying a database, opening a ticket, reading a document. MCP standardises how an agent connects to a tool. Who should be allowed to use each one, and within what limits, is left to each server.
The risk moves from what the model says to what the agent does. And what it does happens in your systems.
Where are the risks with MCP agents?
Each server handles permissions its own way
Every tool an agent uses reads data or carries out actions. And each MCP server handles permissions its own way, or not at all. With three servers it’s manageable; with thirty, nobody knows any more which agent can do what. Credentials end up scattered across configuration files, and permissions live in the memory of whoever set them up.
A tool can change after you approve it
An agent decides what to do with a tool by reading its description. If that description changes after you’ve approved it, what the agent does with it changes too, and nobody reviews it. This is known as a tool “rug pull”: what you approved is no longer what runs.
You will be held to account
When something goes wrong, someone will ask who did what, with which permission and when. “The agent did it” isn’t an answer. You need a record you can trust, and one nobody has been able to touch up afterwards.
What principles should AI agent governance follow?
These seven principles sum up what it takes for an agent to work with real systems without becoming a black box:
| Principle | What it means | What it prevents |
|---|---|---|
| A single entry point | Every MCP server is registered, discovered and routed in one place | Agents connected to tools nobody has inventoried |
| Identity without shortcuts | Every agent and user is verified with your provider (OIDC), without forwarding their credentials | Credentials copied into configs, and agents acting as anyone |
| Per-tool permissions | Which role can use which tool, and within what usage limits | A read-only agent that can also write |
| Pinned tools | Any change to a tool’s definition is detected, compared and held for approval | The silent rug pull |
| Tamper-proof audit | A record of who did what, with which permission and when | Rebuilding an incident from memory |
| Strict isolation | Separation between customers, and operation on air-gapped networks | A mistake in one environment reaching another |
| Human approval where it matters | Sensitive actions wait for a person to approve them | An irreversible deletion decided by the model alone |
None of these principles is new. They are the ones you already apply to the people who access your systems: identity, least privilege, approved changes and logging. What’s new is applying them to an actor that works at machine speed, never gets tired and does exactly what the tool’s description suggests.
The last principle doesn’t need to wait for any new tool. We already apply it in our own products: when an AI assistant operates NovaeOps over MCP, the operations that delete anything ask for explicit confirmation. The AI proposes; a person approves.
What do ENS, DORA and the AI Act ask for?
None of the three mentions MCP, but they all push in the same direction: access control, traceability and the ability to reconstruct what happened. If your agents will touch the systems of a public body or a financial entity, or form part of a high-risk AI system, you will be asked for it.
The timeline gives you room, and it’s worth using well:
- The AI Act’s obligations for high-risk systems have been pushed back to December 2027 and August 2028.
- Spain has not yet transposed NIS2, and the European Commission has taken it to the EU Court of Justice (July 2026).
- Spain’s National Security Framework (ENS) also reaches suppliers that develop or operate systems handling a public body’s information (Royal Decree 311/2022, article 2).
This is an argument for preparation, not urgency. Adding traceability to a system that is already in production costs more than designing it in from the start, and an audit log only helps if it existed before the incident.
What is Praesidix and what stage is it at?
Praesidix, the control gate for your AI agents, is the governance gateway we are designing for agents that use tools over MCP. It is in the lab and has no software yet: we have finished the market and regulatory study, and the next step is a prototype.
Once it exists, Praesidix will sit in front of your MCP servers and decide who can use which tool, with what identity and within what limits. It will validate identity with your provider (OIDC) without forwarding credentials, pin each tool’s definition and hold any change until you approve it. It will keep an audit log that can’t be tampered with, designed for what ENS, DORA and the AI Act require, and it will also run on air-gapped networks.
It will have three security profiles: local, enterprise and high security. And it’s worth saying what it won’t be: an identity provider, a service mesh, a generic API gateway or a language-model proxy. It will rely on your identity provider and live alongside your gateway.
We are looking for organisations about to put agents to work on real systems to design it with, especially in regulated sectors: banking and insurance, infrastructure and high-security environments.
What can you do today to govern your agents?
You don’t need to wait for any tool to get started:
- Take inventory. Which agents you have, which MCP servers they use and which tools those servers expose.
- Separate reading from writing. An agent that only queries doesn’t need tools that modify.
- Keep what you approve. Record each tool’s definition on the day you approve it, and review it when it changes.
- Get credentials out of configuration files. Each agent with its own identity and the minimum permissions.
- Require human approval for anything that can’t be undone.
- Centralise your logs before you need them.
If agents will also use your own tools, AI and developer experience covers how to design your CLI and API for them without losing human control over anything sensitive.
Where do you start?
With the inventory, and with deciding which actions an agent must never take without a person in the loop. If your organisation is about to put agents to work on real systems, let’s design Praesidix together.