Most enterprise AI programs still treat agent risk as a prompt problem.
That made sense when the agent was little more than a chat interface wrapped around a model. You could improve the system prompt, add better instructions, test a few jailbreak patterns, and feel like you had made the system safer.
That model breaks down as soon as agents start doing real work.
Once an agent can read business data, call APIs, invoke MCP tools, open tickets, change records, send messages, or trigger workflows, the prompt is no longer the enterprise boundary. The real boundary becomes the control plane around the agent: identity, tool access, policy enforcement, auditability, observability, and rollback.
This is where the industry is clearly moving. Google’s Agent Gateway guidance points toward governed agent connectivity, identity-aware access, platform policy, and observability. Microsoft Entra Agent ID positions agent identities as first-class identity objects for authentication, authorization, governance, and protection. AWS AgentCore Policy places deterministic controls in front of agent tool access.
Different platforms. Same direction.
Enterprise agent security is becoming a control-plane problem.
The Prompt Is Not the Boundary
Prompts matter. They define intent, behavior, tone, tool-use preferences, and guardrail instructions. A bad prompt can absolutely create operational risk.
But a prompt is not an enforcement layer.
A prompt can tell an agent not to issue a refund above $250. A policy engine can block the refund tool call when the amount is $251.
A prompt can tell an agent not to access HR data. An identity and authorization layer can prevent the agent from receiving a token for the HR API.
A prompt can tell an agent to ask for approval before making a production change. A workflow control can require an approval event before the gateway permits the tool invocation.
That distinction is the foundation of enterprise agent architecture.
Prompts are behavioral guidance. Control planes are operational enforcement.
The risk changes when the agent becomes capable of action. At that point, the question is no longer only “what did the model say?” The better questions are:
| Enterprise Question | Why It Matters |
|---|---|
| Who is this agent? | You need attribution, ownership, lifecycle control, and credential separation. |
| Who is the agent acting for? | User-delegated access and autonomous access have different risk models. |
| What tools can it see? | Tool exposure is an attack surface, not just a developer convenience. |
| What actions can it perform? | Tool-level permissions need to be enforceable outside the prompt. |
| What policy decision was made? | Security teams need evidence, not intent. |
| What did the agent do? | Operations needs traces, logs, audit trails, and incident timelines. |
| How do we stop or roll back the agent? | Production systems need kill switches and safe fallback paths. |
That is the agent control plane.
Control Plane vs. Data Plane for AI Agents
A useful way to frame this is to separate the data plane from the control plane.
The data plane is where agent work happens. It includes model calls, retrieval, memory reads, tool invocations, API calls, and responses back to users or systems.
The control plane decides whether that work is allowed, attributable, observable, and reversible.
Here is the pattern at a high level:
The important thing to notice is that the agent runtime is not trusted simply because the prompt says the right thing. The runtime sits inside a governed path. Identity, gateway, policy, and observability are not add-ons after the proof of concept. They are the enterprise boundary.
Why Vendor Architectures Are Converging Around This Pattern
The details differ by platform, but the architectural direction is consistent.
Google’s Agent Gateway documentation describes the gateway as the network entry and exit point for agent interactions. It uses agent identities as authorization principals, integrates with platform policies, and emits observability telemetry for agent interactions at the network layer. Google’s Agent Identity documentation also emphasizes strongly attested cryptographic identity, SPIFFE-based identity strings, and token protections designed to avoid weaker patterns such as shared service accounts and long-lived keys.
Microsoft Entra Agent ID approaches the problem from the identity side. It gives agents specialized identities in Microsoft Entra ID, supports agent identity blueprints, and extends Microsoft Entra security and governance capabilities to agent identities. Microsoft also calls out that agent activity is logged for compliance and audit. The planning guidance is especially important because it recommends agent identity for most AI agents and discourages regular user accounts or generic service principals for agent workloads.
AWS Bedrock AgentCore approaches the pattern through a set of agent infrastructure services. AgentCore Gateway provides a unified endpoint for agents to discover and reach tools, other agents, and models, while handling authentication, protocol translation, secure credential exchange, observability, and auditing. AgentCore Policy then places deterministic controls in front of tool access by evaluating requests against policies before the tool call proceeds.
The practical takeaway is not that every enterprise should choose one of these stacks. The takeaway is that credible enterprise agent platforms are moving away from prompt-only governance and toward infrastructure-enforced controls.
The Five Control-Plane Capabilities Enterprises Need
Agent Identity
Identity is the starting point because everything else depends on attribution.
An enterprise should be able to answer:
- Which agent made the request?
- Which version or deployment of the agent was running?
- Who owns the agent?
- Was the agent acting on its own authority or on behalf of a user?
- Which credentials, grants, or delegated permissions were involved?
Microsoft’s guidance is useful here because it distinguishes agent identities from traditional application identities and human user identities. Agent identities are designed for scale, lifecycle management, consistent policy application, and retirement without leaving orphaned credentials behind. Microsoft also recommends one agent identity per logical agent when audit fidelity, lifecycle independence, and role separation matter.
That is the right default for enterprise design.
Do not start by giving a fleet of agents one shared service principal. That may be easier for a prototype, but it creates weak attribution and a broad blast radius. Treat agent identities like production security objects: named, owned, scoped, monitored, and retired when no longer needed.
The gateway is where enterprise security starts to become enforceable.
Without a gateway pattern, each agent framework tends to become its own integration island. Developers wire tools directly into the agent, credentials end up close to code, and security teams are forced to review every implementation separately.
A gateway gives the organization a common access path.
Google’s setup guidance states that tools, MCP servers, and API endpoints must be identified and registered, and that Agent Gateway blocks outbound traffic to hosts not registered in Agent Registry. It also states that every Agent Gateway requires an associated authorization policy.
That is a strong enterprise pattern: tools should be registered before they are callable.
AWS AgentCore Gateway follows a similar access-layer theme by exposing tools through a unified interface, handling inbound and outbound authentication, performing protocol translation, and providing secure credential exchange.
The operational design principle is simple:
Agents should not get direct, unmanaged access to every API they might possibly need.
They should get routed access to approved tools through a gateway that can authenticate, authorize, observe, throttle, transform, and revoke access.
Externalized Policy Enforcement
Policy needs to live outside the prompt and outside the agent code path.
That does not mean prompts are irrelevant. It means the final enforcement decision should not depend on whether the model followed instructions.
AWS AgentCore Policy is a clear example of this direction. The documentation describes policy engines associated with gateways, where traffic is intercepted and evaluated before tool access is allowed. It also supports policies written in Cedar and natural-language-assisted policy authoring that generates and validates candidate policies.
Google’s Agent Platform policy model also points in this direction. Agent Gateway can use IAM allow and deny policies to govern communication between agents and services, including other agents, MCP servers, and endpoints. Google also describes Semantic Governance Policies as a layer for non-deterministic LLM behavior, allowing administrators to define security and business rules using natural language constraints.
The architecture lesson is that agent policy has multiple layers:
| Policy Layer | Example Control |
|---|---|
| Identity policy | Which agent identity can request a token? |
| Gateway policy | Which registered tools can this agent invoke? |
| Tool policy | Which action and parameters are allowed? |
| User-context policy | Is the agent acting for a user with permission? |
| Business policy | Is this refund, access request, or change within limits? |
| Safety policy | Does this request involve sensitive data, prompt injection, or prohibited content? |
| Approval policy | Does this action need human approval before execution? |
A mature agent architecture does not collapse all of that into a longer system prompt.
Observability and Auditability
An enterprise agent that cannot be traced is not production-ready.
Agent observability is not just model performance monitoring. It needs to include the execution path: identity, user context, tool selection, tool invocation, policy decision, approval event, response, error, latency, and cost.
Google’s Agent Gateway documentation states that it generates observability telemetry for all agent interactions at the network layer and exports that telemetry to Agent Observability. Microsoft’s Agent ID best practices recommend monitoring sign-in logs, configuration changes, credential events, permission grants, role assignments, unusual token requests, unexpected API access, and agent activity during incident response. AWS AgentCore observability documentation describes built-in metrics for runtime, memory, gateway, tools, and identity resources, with CloudWatch and OpenTelemetry support for broader instrumentation.
For production use, the minimum useful trace should answer:
| Trace Field | Why It Matters |
|---|---|
| trace_id | Correlates the user request, model call, policy decision, and tool call. |
| agent_id | Identifies the agent as an accountable actor. |
| agent_version | Connects behavior to a deployable artifact. |
| user_context | Shows whether the agent acted autonomously or on behalf of a user. |
| tool_name | Identifies the system or function invoked. |
| tool_parameters_summary | Supports investigation without dumping sensitive payloads into logs. |
| policy_decision | Records allow, deny, dry-run, approval-required, or escalation. |
| policy_version | Makes policy behavior reproducible after changes. |
| approval_id | Links high-risk actions to human authorization. |
| result_status | Shows success, failure, timeout, or rollback. |
This is where many pilots fail the production test. The agent may work, but nobody can explain exactly what it did after the fact.
Rollback and Kill Switches
Rollback is rarely discussed in agent demos, but it is one of the most important enterprise controls.
A production agent system needs several ways to stop damage without waiting for a code deployment:
| Rollback Lever | What It Controls |
|---|---|
| Disable agent identity | Stops the agent from obtaining new tokens. |
| Revoke delegated grants | Removes access the agent had on behalf of users. |
| Detach gateway targets | Prevents access to a specific tool or API. |
| Switch policy to deny | Blocks a risky action class quickly. |
| Switch policy to approval-only | Keeps the workflow alive while forcing human review. |
| Roll back policy version | Restores the last known-good authorization rules. |
| Roll back agent version | Reverts model orchestration, prompt, routing, or tool-use logic. |
| Quarantine memory or retrieval index | Stops suspect context from influencing future runs. |
This is also why agent configuration should be managed like production infrastructure. Policies, tool registrations, gateway configuration, identity assignments, and approval rules should be versioned, reviewed, and deployed through controlled change paths.
A Practical Agent Control-Plane Policy Example
The following YAML is intentionally platform-neutral. It is not meant to be pasted directly into Google Cloud, Microsoft Entra, or AWS. Treat it as a reference model for the controls your platform-specific implementation should express through IAM, Conditional Access, Cedar, gateway configuration, MCP server policy, or an internal policy engine.
The example governs a customer-support refund agent. It allows read-only customer lookup, permits small refunds, requires approval for higher-risk actions, denies unregistered egress, and defines mandatory observability fields.
apiVersion: dtd.ai/v1alpha1
kind: AgentAccessPolicy
metadata:
name: customer-support-refund-agent-prod
owner: customer-operations
environment: production
policyVersion: 2026.07.02
changeTicket: CHG-2026-0714
description: >
Control-plane policy for a production support agent that can
read customer records and issue bounded refunds through approved tools.
spec:
mode: enforce
defaultDecision: deny
subjects:
agents:
- id: agent://prod/customer-support/refund-agent
requiredLabels:
businessOwner: customer-operations
technicalOwner: ai-platform-team
dataAccessTier: confidential
lifecycleState: active
userContext:
requiredFor:
- crm.readCustomer
- refunds.issueRefund
allowedGroups:
- CustomerSupportTier2
- CustomerSupportManagers
requireUserTokenAudienceMatch: true
gateway:
registeredToolsOnly: true
denyUnregisteredEndpoints: true
allowedProtocols:
- mcp
- https
blockedDirectEgress:
- internet
- unmanaged-saas
- unknown-mcp-server
tools:
- name: crm.readCustomer
endpoint: mcp://crm-prod/customer.read
decision: allow
constraints:
allowedFields:
- customerId
- accountStatus
- orderHistory
- supportCaseHistory
deniedFields:
- fullPaymentCard
- taxIdentifier
- authenticationSecrets
requireCaseId: true
- name: refunds.issueRefund
endpoint: mcp://payments-prod/refund.issue
decision: conditionalAllow
constraints:
maxAmountUSD: 250
maxRefundsPerCustomerPerDay: 2
requireCaseId: true
requireCustomerTenantMatch: true
denyIf:
- userRiskLevel in ["high", "critical"]
- agentRiskLevel in ["high", "critical"]
- customerAccountStatus in ["fraud_review", "legal_hold"]
requireApprovalWhen:
- amountUSD > 100
- refundReason in ["manual_exception", "policy_override"]
- confidenceScore < 0.85
- name: ticketing.updateCase
endpoint: mcp://itsm-prod/case.update
decision: allow
constraints:
allowedActions:
- addComment
- setStatusPendingCustomer
- setStatusResolved
deniedActions:
- deleteCase
- modifyAuditHistory
approvals:
provider: workflow://service-now/ai-agent-approvals
approvalTimeoutMinutes: 30
onTimeout: deny
approverGroups:
- CustomerSupportManagers
recordApprovalIdInTrace: true
observability:
required: true
traceProvider: otel
requiredEvents:
- agent.invoked
- identity.token_requested
- gateway.tool_selected
- policy.evaluated
- approval.requested
- approval.completed
- tool.invoked
- tool.completed
- rollback.executed
requiredFields:
- trace_id
- agent_id
- agent_version
- policy_version
- user_id_hash
- user_groups
- tool_name
- tool_action
- decision
- decision_reason
- approval_id
- change_ticket
- result_status
sensitiveDataHandling:
redactPayloads: true
storeParameterSummaryOnly: true
blockSecretsInLogs: true
retention:
securityLogsDays: 365
debugTracesDays: 30
rollback:
killSwitches:
- disableAgentIdentity
- revokeDelegatedGrants
- detachGatewayTarget
- setPolicyModeDeny
- requireApprovalForAllToolCalls
automaticRollbackWhen:
- deniedRequestsPerHour > 50
- failedRefundToolCallsPerHour > 20
- anomalousTokenRequestsDetected == true
notify:
- ai-platform-oncall
- security-operations
- customer-operations-owner
The policy shows the operational shape of a governed agent. The controls are not only about “what the model should do.” They define who the agent is, which users it may act for, which tools it can invoke, which parameters are acceptable, when approval is required, what telemetry must exist, and how the system can be shut down safely.
That is the difference between an agent prompt and an agent platform.
Implementation Sequence: How to Build the Control Plane Without Stalling Delivery
The common mistake is trying to solve the entire control plane in one architecture review. That creates a governance backlog and sends teams back to unmanaged prototypes.
A better approach is to phase the controls.
Inventory Agents and Assign Ownership
Start with visibility. Identify which agents exist, who owns them, what runtime they use, what tools they call, and whether they act autonomously or on behalf of a user.
This phase should produce an agent register, not just a slide.
Minimum fields:
| Field | Example |
|---|---|
| Agent name | customer-support-refund-agent |
| Business owner | Customer Operations |
| Technical owner | AI Platform Team |
| Runtime | Gemini Enterprise, Azure-hosted agent, Bedrock AgentCore, Kubernetes, internal framework |
| Identity model | Agent identity, workload identity, service principal, user-delegated |
| Tool access | CRM read, refund issue, ticket update |
| Data classification | Confidential |
| Risk tier | Production action-taking agent |
| Rollback owner | AI Platform On-call |
Next, remove direct tool sprawl.
This does not require every tool in the company to be gateway-managed on day one. Start with high-impact tools: payment actions, user administration, HR data, ticket closure, production change execution, customer messaging, and anything that changes financial or security state.
The design rule is clear: if the tool can change business state, it should be behind a governed access path.
Externalize the Highest-Risk Policies
Then move to more nuanced controls such as semantic governance, risk scoring, data classification, and confidence-based approval.
Instrument the Execution Path
Observability needs to be designed before incident response depends on it.
A trace that only shows the model response is not enough. The control plane should capture identity, token flow, policy decision, gateway routing, tool invocation, approval event, and result status.
This is where security and operations need to agree on retention, redaction, and escalation. Logging raw prompts and full tool payloads may create its own data leakage problem. A production control plane should preserve evidence without turning observability into another sensitive-data lake.
Build Rollback Into Release Management
Every production agent release should include a rollback plan.
That plan should cover:
- agent runtime version
- prompt or instruction version
- tool schema version
- policy version
- gateway target version
- identity grants
- approval workflow
- memory or retrieval configuration
A rollback plan that only redeploys the previous prompt is incomplete.
Common Design Mistakes
Treating Agent Identity as a Naming Convention
Calling something refund-agent-prod is not the same as giving it a governed identity. The identity needs lifecycle, ownership, permissions, logs, credential management, and revocation.
Many agent prototypes expose too many tools because it improves demo flexibility. In production, that increases tool-selection risk, prompt-injection impact, and blast radius.
The agent should see the tools required for its job, not the tools that happen to exist.
Logging Output but Not Decisions
A final answer is not an audit trail. Security teams need the decision path: what the agent attempted, what the gateway allowed, what the policy denied, what approval was required, and what system of record changed.
Mixing User-Delegated and Autonomous Access Without a Boundary
An agent acting on behalf of a user and an agent acting as itself are different patterns. Microsoft’s Conditional Access documentation separates delegated user access from application-only autonomous access, with different token subjects and policy targeting.
Designs that blur those modes make authorization harder to reason about.
No Fast Disable Path
If the only way to stop an agent is to ask the development team to redeploy, the system is not production-governed. Security and operations need a documented kill switch that can disable identity, revoke grants, block tools, or force approval-only mode.
What This Means for Enterprise AI Strategy
The enterprise AI roadmap should not be “more agents, better prompts.”
It should be:
- Fewer unmanaged agents.
- Stronger agent identities.
- Tool access through governed gateways.
- Policies enforced outside agent code.
- Observability that can support audit and incident response.
- Rollback paths that operations can execute.
This does not make prompt engineering irrelevant. It puts prompt engineering in the right place.
Prompts shape agent behavior. The control plane governs agent authority.
That distinction is what separates a useful prototype from an enterprise platform.
Conclusion
The next stage of enterprise AI will not be won by teams that write the longest system prompts. It will be won by teams that can let agents act safely inside real business systems.
That requires a control plane.
Identity tells the enterprise who the agent is. Gateways define how the agent reaches tools. Policy determines what the agent is allowed to do. Observability proves what happened. Rollback gives operations a way to recover when behavior, policy, data, or tool integrations go wrong.
Google, Microsoft, and AWS are all pointing toward this same architectural reality from different directions. The details will continue to evolve, and the product names will change, but the enterprise pattern is clear.
Before adding more prompts, build the boundary that makes agent action governable.
External Sources
Google Cloud Agent Gateway overview
https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/agent-gateway-overview
Google Cloud Agent Identity overview
https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/agent-identity-overview
Google Cloud Agent Gateway setup
https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/set-up-agent-gateway
Google Cloud Agent Platform policies overview
https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/policies/overview
Microsoft Entra Agent ID overview
https://learn.microsoft.com/en-us/entra/agent-id/what-is-microsoft-entra-agent-id
Microsoft Entra agent identities overview
https://learn.microsoft.com/en-us/entra/agent-id/what-are-agent-identities
Microsoft Entra Agent ID architecture planning
https://learn.microsoft.com/en-us/entra/agent-id/how-to-plan-agent-identity-architecture
Microsoft Entra Agent ID best practices
https://learn.microsoft.com/en-us/entra/agent-id/best-practices-agent-id
Microsoft Entra Conditional Access for agents
https://learn.microsoft.com/en-us/entra/identity/conditional-access/agent-id
AWS Bedrock AgentCore Gateway documentation
https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html
AWS Bedrock AgentCore Policy documentation
https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html
AWS Bedrock AgentCore Observability documentation
https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability-configure.html
