Tag: Control-Plane

How enterprises can govern AI agents across identity, tool access, policy, traceability and intervention.

Most teams deploying AI agents start with a familiar instinct.

• Write a good system prompt.
• Add some guardrails.
• Connect a few tools.
• Test the happy path.

That may work in a demo. It does not survive production, an audit, or an incident.

The reason is simple: prompts and guardrails mostly shape what an agent says. In production, the bigger governance question is what an agent is allowed to do.

• Can it retrieve customer data?
• Can it update a record?
• Can it trigger a workflow?
• Can it approve a refund?
• Can it send a message?
• Can it call another system?
• Can it act without a human in the loop?

Once agents move from answering questions to taking action, the governance problem changes completely. You are no longer just managing response quality.

You are managing authority, identity, tool access, runtime policy, traceability, intervention and recovery.

That is where the idea of an AI Agent Control Plane becomes important.

A control plane is not a dashboard. It is not a policy document. It is not a prompt template with guardrails.

A control plane exists when a system can make and enforce decisions about intent, authority and boundaries at runtime.

For enterprise AI, especially in regulated environments, this becomes the difference between an impressive prototype and a production-grade agentic system.

What an agent control plane needs to do

A complete AI agent control plane needs six core capabilities.

First, it needs to understand intent.

The system must be able to reason about why the user is asking the agent to act, not just whether a tool call is technically valid.

Second, it needs to manage authority.

The decision about whether an action is allowed should live outside the model. The model can propose, but the platform should decide.

Third, it needs explicit identity.

Every meaningful action should be attributable to a user, an agent and a system identity. Shared service accounts and opaque execution paths are not enough for production.

Fourth, it needs coordination.

As agents interact with tools, workflows and potentially other agents, the platform needs rules for sequencing, conflicts, dependencies and failure handling.

Fifth, it needs decision traceability.

Logs can tell you what happened. A proper control plane should help you understand why it happened.

Sixth, it needs intervention.

The organisation must be able to pause, constrain, override, revoke or stop agent execution when needed.

These six capabilities are easy to list and hard to build.

Until recently, many organisations had to assemble most of this themselves using IAM, API gateways, CloudTrail, custom middleware, observability tools and manual approval flows.

On AWS, more of this pattern is now becoming buildable through services such as Amazon Bedrock Agents, action groups, guardrails, identity controls, gateways, policy enforcement, tracing and operational monitoring.

But the order matters.

You cannot govern what you cannot name.

You cannot constrain what you cannot route.

You cannot audit what you cannot trace.

You cannot intervene in what you have not designed to control.

So the control plane needs to be built in layers.

Layer 1: The design layer

The design layer defines what the agent is allowed to be.

This starts with intent, authority and identity.

Most enterprise systems already understand user identity. They know who logged in, what role they have and what permissions apply.

Agents introduce a more complex question.

It is no longer enough to know who the user is. You also need to understand what the user is trying to get the agent to do.

A user may have access to customer information. That does not automatically mean they should be able to instruct an agent to update customer records, approve compensation, cancel a policy or trigger a payment.

This is why intent becomes a governance concern.

A user might say:

“Can you help this customer?”

“Sort this refund out.”

“Give them £50 compensation.”

“Approve the claim if everything looks fine.”

Those requests may sound similar, but they carry very different levels of operational risk.

The control plane needs to distinguish between information, recommendation, drafting, workflow initiation and final action.

Low-risk intent may only require a standard response.

Medium-risk intent may require retrieval, calculation or recommendation.

High-risk intent may require policy checks, human approval, restricted tools or refusal.

The same principle applies to authority.

If an employee cannot approve a payment directly, they should not be able to approve it indirectly through an agent.

If a user can view a record but not modify it, the agent should not be able to modify it on their behalf.

If a business process requires four-eyes approval, the agent should not bypass that control because the request arrived through natural language.

The agent should inherit authority from the right context, not from technical convenience.

This is also where agent identity matters.

In many early agent systems, the agent runs behind a broad service account. That may be convenient, but it weakens accountability.

For production, every meaningful action should be attributable across three identities:

The requesting user.

The executing agent.

The target system identity.

That distinction matters for audit, compliance, incident response and operational trust.

The organisation should be able to tell whether an action was taken by a human, recommended by an agent, approved by a human after agent recommendation, or executed automatically by an agent.

Without that foundation, the rest of the control plane is weak.

You cannot govern tool access properly if intent is unclear.

You cannot audit decisions properly if identity is opaque.

You cannot operate safely if authority is hidden inside prompts, plugins or over-permissive service accounts.

Layer 2: The execution layer

The design layer decides what an agent is allowed to be.

The execution layer decides what it is allowed to do.

This is where most agent deployments quietly go wrong.

An agent that only answers questions creates information risk.

An agent that can call APIs, update records and trigger workflows creates action risk.

That is why tool access becomes one of the most important control boundaries in an agentic architecture.

Most agent deployments grow by accident.

A developer wires up a few tools. The agent works in testing. More tools are added. Another integration is included. A workflow is exposed. A database query is added. An internal API becomes available.

By the time the agent reaches production, it may have more access than anyone originally intended.

With agents, the question is not:

Can the agent call this tool?

The better question is:

Should this agent, for this user, with this intent, in this context, call this tool with these parameters?

That is a different governance model.

Tool design is governance design.

Suggestive Agent	Acting Agent
Calculate refund	Issue refund
Retrieve customer policy	Update customer policy
Draft response	Send response
Recommend approval	Approve request

These distinctions matter because agents can make complex operations feel deceptively simple.

A user may type one sentence, but behind that sentence could be retrieval, reasoning, tool selection, API calls and state-changing operations.

The control plane needs to make those boundaries explicit.

One useful pattern is to group tools by risk level.

Read-only tools allow the agent to retrieve or summarise information.

Advisory tools allow the agent to calculate, classify or recommend.

Drafting tools allow the agent to prepare outputs but not send or commit them.

Action tools allow the agent to change state in another system.

High-impact tools allow the agent to trigger financial, legal, operational or customer-impacting outcomes.

Each category should have different controls.

• Read-only tools may require standard authentication and logging.
• Advisory tools may require validation and confidence thresholds.
• Drafting tools may require human review before completion.
• Action tools may require runtime policy checks, approval workflows or scoped permissions.
• High-impact tools may require human-in-the-loop approval, stronger monitoring and stricter operational controls.

On AWS, Amazon Bedrock Agents can expose business capabilities through action groups rather than giving agents broad access to backend systems.

That distinction is important.

The goal should not be “give the agent database access” or “give the agent CRM access”.

The goal should be to expose specific, governed business actions:

Check claim status -> Calculate refund eligibility -> Generate case summary -> Draft customer response -> Create escalation task -> Submit approval request

Each tool should have a clear purpose, a clear risk level and a clear control model.

This is where gateways become important.

Instead of allowing every agent to connect directly to every backend API, the architecture should move toward a governed path:

Agent → Gateway → Approved tool → Controlled execution.

A gateway gives the organisation one place to manage approved tools, schemas, authentication, policy checks, audit logging and revocation.

That is a very different model from each agent maintaining its own direct connections to systems.

Direct connections create too many enforcement points. Too many enforcement points become hard to govern. They are hard to observe. They are hard to unwind during an incident.

A governed tool layer gives the organisation a clearer boundary.

The agent should not discover enterprise power directly. It should receive controlled access through approved tools.

Policy checks then decide whether a tool call is allowed at runtime.

This matters because the same tool may be safe in one context and unsafe in another.

Reading a customer record may be low risk.

Updating a customer address may be medium risk.

Issuing a refund may be conditional risk.

Cancelling a policy may be high risk.

Deleting a customer record may be restricted.

The model should not decide this alone.

The model can propose.

The platform should decide.

Guardrails are still important, but they are not enough.

Guardrails help shape what the agent says. They can help with content safety, topic boundaries, grounding, sensitive information and policy-aligned responses.

But response guardrails do not replace permission design.

You need both.

Response guardrails ask:

Is the agent saying something it should not say?

Execution guardrails ask:

Is the agent doing something it should not do?

Both are required.

The execution layer should follow a simple pattern:

User request.

Intent classification.

Policy check.

Human approval where required.

Controlled tool execution.

Evidence capture.

That is the difference between an agent with tools and an agent with governed capability.

The best agent architecture is not the one with the most tools.

It is the one where every tool call has a reason, a permission, a boundary and an evidence trail.

Layer 3: The operations layer

A control plane that can authorise and execute still has to be observable and stoppable once agents are live.

This is the layer that turns a design into something you can defend in an audit and recover during an incident.

Traditional systems focus on transactions, API calls, logs, metrics and errors.

Agents introduce a new requirement.

Knowing what happened is no longer enough.

You also need to understand why it happened.

For a normal application, a production issue might be traced through a request ID, service logs, metrics and a stack trace.

For an agent, the execution path may include the user request, recognised intent, retrieved context, prompt construction, model response, tool selection, policy evaluation, guardrail assessment, human approval and downstream system execution.

If the agent makes the wrong decision, the organisation needs to reconstruct the decision path.

What did the user ask?

What intent was recognised?

Which agent handled the request?

What context was retrieved?

Which tools were considered?

Which tool was selected?

What parameters were passed?

Which policies were evaluated?

Were any guardrails triggered?

Was a human involved?

What action was finally taken?

This turns traceability into more than debugging.

It becomes part of the control plane.

A useful way to think about traceability is through sessions, traces and spans.

The session is the overall interaction.

The trace is the path of one request through the system.

The spans are the individual steps: LLM call, knowledge lookup, policy check, tool invocation, approval step or downstream API call.

The important point is not just collecting logs.

It is propagating trace context across the full agent journey.

A log tells you what happened at a point in time.

A connected trace helps you understand how the decision moved through the system.

That is what allows engineering, risk, security and operations teams to answer a harder question:

Why did this agent take this action?

On AWS, this pattern can be supported through Bedrock agent traces, CloudWatch, OpenTelemetry-based instrumentation and integration with enterprise observability platforms.

The exact tooling may vary, but the principle does not.

Instrument before the incident.

Not during one.

Traceability answers one question:

Can we reconstruct the full path from request to outcome?

But traceability is not enough.

You also need intervention.

There will be times when the agent should not continue.

The user’s intent may be ambiguous.

The action may be too risky.

The policy may be unclear.

The confidence level may be too low.

The downstream system may be unavailable.

The agent may be operating outside approved behaviour.

In these cases, the system needs a way to pause, escalate, reroute or stop the agent.

Intervention can take different forms.

Human approval before execution.

Human review before sending a response.

Automatic escalation to a specialist team.

Runtime blocking of specific tools.

Temporary reduction of agent capability.

Revocation of agent credentials.

Fallback to read-only mode.

Routing to a safer configuration.

Kill switches for high-risk workflows.

The important point is that intervention should not be improvised during an incident.

It should be designed into the control plane.

There is also a need for honesty here.

Some intervention controls are well understood.

Blocking a tool call before execution is achievable.

Denying a policy decision at runtime is achievable.

Revoking credentials is achievable.

Disabling a specific tool is achievable.

Moving an agent to read-only mode is achievable if the architecture supports it.

Other intervention problems are harder.

Cleanly stopping an in-flight agent session without leaving partial state is still difficult.

Detecting cross-agent deadlocks or unsafe coordination patterns is still immature.

Recovering from incorrect real-world actions may require business compensation, manual correction or formal incident handling.

These are not just AWS gaps.

They are broader agentic AI operating-model challenges.

This is why boundary design matters.

You constrain the agent at the tool and policy boundary because you may not be able to reliably interrupt every failure mid-reasoning.

The operations layer also needs runbooks.

A production agent should have clear answers to operational questions:

How do we disable a specific tool?

How do we tighten guardrails during an incident?

How do we revoke an agent’s access?

How do we move the agent into read-only mode?

How do we identify affected users or transactions?

How do we replay or review agent traces?

How do we escalate high-risk failures?

How do we recover from an incorrect action?

How do we prove what happened to risk, compliance or audit teams?

This is where the operating model matters as much as the technology.

A good agent control plane needs clear ownership.

Who owns the agent’s behaviour?

Who owns the tools?

Who owns the policies?

Who owns the prompts?

Who owns the knowledge base?

Who owns the incident response process?

Who decides when the agent can move from advisory mode to action mode?

Without clear ownership, agent governance becomes fragmented.

The AI team owns the model.

The platform team owns the infrastructure.

The product team owns the experience.

The security team owns access.

The risk team owns policy.

The operations team owns incidents.

But the agent sits across all of them.

That is why the control plane needs to be treated as a cross-functional capability, not just an engineering implementation.

The end-to-end implementation order

When the three layers come together, the implementation order becomes the lesson.

Start with identity.

Give every meaningful agent workload its own attributable identity. Avoid broad shared service accounts where possible. Make sure actions can be tied back to the requesting user, executing agent and target system.

Then design the tool layer.

Do not expose broad backend access. Expose specific business actions with clear schemas, validation rules and risk levels.

Then introduce the gateway.

Route agent action through a governed layer so tool access, authentication, policy checks, logging and revocation are not scattered across every agent.

Then apply runtime policy.

Let the model propose, but let the platform decide. The same tool may be allowed, denied or escalated depending on user, intent, context and parameters.

Then add guardrails.

Use guardrails to shape behaviour and reduce unsafe responses, but do not confuse them with permission design.

Then build traceability.

Capture the full path from request to outcome. Logs are useful, but connected traces are what help you understand why an agent acted.

Then design intervention.

Make it possible to block, pause, revoke, escalate and degrade capability before something goes wrong.

Finally, operate agents as production systems.

Monitor agent-specific signals such as tool-choice patterns, policy-denial rates, escalation frequency, session length, guardrail triggers, failed tool calls and unusual action volumes.

The operational moat is not the model.

It is the discipline of treating agent behaviour as a first-class production surface.

What remains unsolved

It is tempting to describe the control plane as a solved problem.

It is not.

Some parts are now practical.

Identity is practical.

Tool gateways are practical.

Runtime policy checks are practical.

Guardrails are practical.

Trace collection is practical.

Approval flows are practical.

But other areas remain immature.

In-flight termination is still difficult.

Cross-agent coordination is still early.

Policy design for ambiguous intent is still hard.

Recovery from incorrect real-world actions is still business-specific.

Explainability is still incomplete.

Evaluation of agent behaviour over long-running workflows is still evolving.

That honesty matters.

Enterprise leaders do not need vendor optimism.

They need a realistic view of what can be controlled today, what requires careful design, and what still needs operational caution.

The right answer is not to avoid agents.

The right answer is to introduce autonomy gradually, with clear boundaries.

Start with read-only use cases.

Move to advisory use cases.

Then drafting.

Then human-approved action.

Then carefully constrained automation.

Autonomy should be earned.

Not assumed.

Controlled autonomy

The goal of an AI Agent Control Plane is not to block agents.

The goal is to make autonomy safe enough to scale.

Enterprises do not need agents that can do everything.

They need agents that can do the right things, within the right boundaries, with the right level of oversight.

That means designing for controlled autonomy.

Autonomy without control creates risk.

Control without autonomy creates another chatbot.

The value sits in the middle.

Agents should be able to act, but only within clear policy boundaries.

They should be able to use tools, but only through governed interfaces.

They should be able to support users, but not bypass business authority.

They should be able to operate in production, but with traceability, intervention and recovery built in.

The question is no longer:

Can we build an AI agents?

The better question is:

Can we operate them safely in production?

That is what the Agent Control Plane is really about.