Post-deployment AI governance: control and policy enforcement once agents are live
This is governance and policy enforcement sitting between your AI agents and your MCP servers. It keeps AI systems inside boundaries you have defined, and it prevents misuse of agents and unauthorised interactions between them and the servers they can reach.
Where the control point sits
The enforcement point goes between the agent and the MCP server, which is the only place both sides of the interaction are visible.
- Decide
The agent chooses an action
A model working on a task decides it needs a tool. Nothing about that decision is constrained by the model itself, which is why the constraint has to live outside it.
- Leave
The call heads for an MCP server
This is the moment the system stops reasoning and starts acting on something real. Everything worth governing after deployment happens on this hop.
- Check
The execution policy is applied
The call is measured against the policies you defined: which agent, which server, which interaction. Anything outside the boundary does not proceed.
- Act
The server does the permitted work
Permitted calls run normally. The agent keeps its usefulness, and the difference is only visible when something tries to step outside the boundary.
- Repeat
The same policy meets the next call
Every call from every agent takes this route, so a boundary defined once applies to the agent added next week without anyone rewriting a prompt.
The four things organisations buy this for
These are the outcomes the solution is built around, and they matter most where AI systems already run at scale.
Define execution policies
Write down what your agents may and may not do, once, in a place that holds for every agent rather than inside each one's prompt.
More on AI governance →Maintain compliance
Compliance rests on boundaries that are enforced rather than described, which is what an auditor is asking about when they ask how AI is controlled here.
Secure agent to server communication
The link between an agent and an MCP server is a route into real systems. It is governed here rather than trusted by default.
Protect AI infrastructure from abuse
Misuse of agents and unauthorised interactions are prevented at the enforcement point, so one compromised or badly instructed agent does not become an open door.
See it in a public sector case →What changes on the day this goes in
The left column is what an ungoverned agent estate looks like, and the right is what the enforcement point makes true instead.
- An agent can reach any server it knows aboutAn agent reaches only what policy permits
- Boundaries live inside prompts and good intentionsBoundaries are defined once and enforced outside the model
- Misuse is discovered after the fact, if at allUnauthorised interactions are refused when attempted
- Compliance is a claim someone makes in a meetingCompliance rests on boundaries that are actually enforced
- Every new agent widens the surface areaA new agent inherits the policies already in force
What operating within defined boundaries actually means
Governance is only real when a refusal is possible, so these are the points where the system can say no.
The agent is identified before it is trusted
Enforcement starts from knowing which agent is calling. A policy that cannot tell one agent from another is a preference, not a control.
The server it may talk to is a decision, not an accident
Which MCP servers an agent can reach is set by policy. Reachability stops being a side effect of network configuration.
Interactions outside the policy are refused
Unauthorised interactions do not partially succeed. The point of putting the check on the hop is that refusal happens before anything real is touched.
Misuse of an agent is contained
If an agent is pushed to do something it should not, the boundary holds regardless of how convincing the instruction that reached the model was.
A new agent does not arrive ungoverned
Policies are defined outside the models, so an agent added after the build is measured against the same boundaries as the ones already running.
The control layer in four figures
The same points made above, stated as figures rather than paragraphs.
How much of this an estate actually needs
The value rises sharply with the number of agents and the number of servers they share.
- One
A single agent, a single server
One team built both ends and one person can hold the whole thing in their head. A policy layer here mostly adds ceremony to something already contained.
- Several
Several agents over shared servers
The first point where nobody can answer what every agent is allowed to reach. This is where a defined execution policy starts paying for itself.
- Scale
An estate of agents in production
Agents outnumber the people who wrote them, and servers are shared across teams. This is the case the solution is built for.
How the work is sequenced
The same three-phase shape we use across engagements, applied to your agent estate rather than to a data platform.
- Week 1
Fixed-fee audit
Two calls and a one-pager you keep either way: which agents exist, which servers they reach, and where the boundaries are currently undefined.
- Weeks 2-6
Build the enforcement point
Policies written down, the control point placed between agents and MCP servers, and refusals proven on real traffic rather than on a diagram.
- Week 7 onward
Operate
Policy is not a delivery, it is a running concern. New agents, new servers and new tools arrive, and the boundary has to keep pace with them.
- Throughout
A pod of three
One team, three people, across the audit, the build and the operate phase, so the people enforcing the policy are the people who wrote it.
Where the audit falls in the six weeks
The audit is the first week of the same window that ends in a production-grade artefact.
Where this is the wrong answer
There are several cases where the honest recommendation is that you do not need this yet.
Nothing is in production yet
Post-deployment governance controls a system that is already live. If you are still deciding whether the AI is good enough to deploy, the question is evaluation, and our pre-deployment assurance work is the right starting point.
Your agents do not talk to MCP servers
The control point described on this page sits on agent to MCP server traffic. If your agents reach tools by some other route, tell us in the first call rather than the fourth week, and we will say whether this shape fits.
The problem is answer quality, not permission
This layer decides what an agent is allowed to do. It does not make the model's output better. If your complaint is that the answers are wrong rather than that the actions are unbounded, you want evaluation instead.
You need a certificate to point at
We describe capabilities, not certifications. If your procurement needs a named standard held by a supplier before anything can start, better that comes out now than after an audit you have paid for.
One person built and runs the whole thing
A single agent over a single server, owned end to end by the person who wrote it, is already governed by the fact that one head holds all of it. Adding a policy layer there buys process, not safety.
Who is doing the work
Firm-level facts rather than product metrics, because this solution is delivered through an engagement.
Questions buyers put to us
The four that come up in almost every first conversation about governing a live agent estate.
Is this a product I can buy off the shelf, or a project?
It arrives through an engagement. Week one is a fixed-fee audit with two calls and a one-pager you keep whatever you decide next. Weeks two to six build the enforcement point and prove it on your own traffic. Week seven onward is operate, because agents, servers and tools keep arriving after the build is finished.
How does this differ from pre-deployment AI assurance?
Assurance runs before the system goes live and asks whether the AI is good enough to deploy, by evaluating and benchmarking it. This page is about what happens afterwards: what a live agent is permitted to do, which servers it may reach, and what it is stopped from doing. Most organisations need both, at different points.
Does putting this in make us compliant?
It gives you the thing compliance rests on: boundaries that are actually enforced between your agents and your MCP servers, rather than written down and hoped for. That is not the same as holding a certification, and we make no certification claim here. If a specific standard gates your procurement, raise it before you shortlist.
Will this slow our agents down or break what already works?
Permitted calls carry on as before. The difference shows up only when something tries to act outside the boundary you defined, which is the point. The Week 1 audit exists partly to find the interactions your agents genuinely depend on, so that the first policy you deploy does not refuse work the business needs.
Start with the audit and find out what your agents can currently reach
Two calls, a fixed fee, and a one-pager you keep either way: the agents you run, the MCP servers they reach today, and where boundaries are undefined. If your estate is small enough that a policy layer only adds ceremony, we will say so.