Keeping control after access, with authorisation that is provable, revocable, and self limiting.
AI agents are getting very good at accessing your data. But once they have it, who is still in control?
Giving AI access to your data is becoming easy. Keeping control of it afterwards and proving exactly what happened is the harder problem, and it gets far less attention than the race to connect.
The part the hype skips
The industry is racing to connect AI agents to everything: your bank, your email, your CRM, your health records, your business systems. Standards like MCP are making those connections almost trivial. But connecting an agent to your data is only the beginning. The real questions start after access is granted.
It is a one way door. Once an AI agent reads your data, it may enter the model's context, its logs, its memory, or downstream processing. You can control access before the data is shared, but revoking permission later does not erase what an agent has already received.
You cannot always see what happened. An agent accesses your data, reasons over it, maybe calls another tool or delegates part of the task to another agent, and eventually you get an answer. But can you independently prove which data it actually accessed, where it came from, which agent accessed it, whether it was used for the purpose you authorised, and whether another agent received it with the same authority, or more? In most systems today, not easily.
Authority can quietly grow. This may be the biggest one. An agent starts with permission to do one thing, delegates to another agent, which calls another service, and the chain continues. Where is the original user's consent in all of that, and how do you know authority did not expand along the way? Delegation should never create more authority than the user granted.
Connecting AI is the easy part. The hard part is everything after the door.
Stay in control after access, not just at the door
Imagine a thin control layer between your data and the agents accessing it. Not another dashboard. Not another policy document. A layer that makes authorisation technically enforceable and independently verifiable. Every request is checked against a cryptographically verifiable authorisation that defines who may access the data, what they may access, why, for how long, and under what conditions. Three principles become fundamental.
Provable
You can independently verify what data an agent was given, where it came from, which agent received it, whether it was altered, and what authorised the access. Not “trust our logs”, but “here is the evidence, verify it yourself.”
Revocable
Authorisation can be withdrawn in real time. It will not erase what an AI has already seen, but it can stop further retrieval and downstream access the moment permission is withdrawn, even mid task. The shift is from “permission was granted once” to “permission stays continuously enforceable.”
Self limiting
When an agent delegates to another agent, authority can only move within the original permission. It can shrink. It cannot silently expand. If Agent A can access transactions for one purpose, Agent B cannot suddenly get broader access just because the task was handed over. Delegation should propagate constraints, not amplify authority.
Turn “trust us” into “prove it”
Most AI governance today lives in policies, risk assessments, documentation, and compliance checklists. All important, but they mostly describe what should happen. What if the system also produced independently verifiable evidence of what actually happened?
A security team, auditor, or regulator could verify which agent accessed which data, on whose behalf, from which source, for what purpose, under what authorisation, when, whether it was modified, whether authority was delegated, and whether that delegated authority stayed within the original boundaries. That is the shift from policy based trust to evidence based verification.
A simple way to think about it
Today: user, then consent, then an MCP connector, then an AI agent.
The next layer: user, then cryptographically verifiable authorisation, then the data provider, then policy, provenance, and continuous enforcement, then the agent connector, then the AI agent, then a delegated agent, then verified audit evidence.
The connector answers: “Can the agent get the data?” The control layer answers: “Was it authorised, what exactly did it receive, what happened to that authority, and can we prove it?”
Connecting AI to data is becoming commoditised. Controlling what happens next is the real problem. The future of AI governance depends less on controlling the door and more on making everything after the door independently verifiable.
If you are building with agents: how are you proving what an agent actually did once it had access?
The views expressed are the author's own and do not represent those of any employer or affiliated organisation.