Imagine a global organization where several AI agents can already review contracts, trigger integration workflows, update orders or take action in an ERP.
The problem arises when IT realizes it cannot accurately answer basic questions:
- which agent performed an action,
- on whose behalf,
- with what permissions,
- under which policy,
- and what the actual outcome was in the target system.
This is not a marginal concern. 82% of organizations report having unknown agents in their infrastructure, and only 21% have a formal decommissioning process (Cloud Security Alliance, January 2026). According to Gartner, 74% of application leaders consider AI agents a new attack vector (May–June 2025).
Agentic Enterprise Architecture addresses precisely this problem, how to integrate agents that can make decisions and execute actions within the enterprise architecture without giving up identity, authorization, traceability and control.
The central element is an Agent Control Plane, a governance layer positioned between the agent’s decision and execution against APIs, applications and core systems.
What changes with Agentic Enterprise Architecture?
The fundamental change is that integration is no longer governed solely by predetermined flows.
In a traditional architecture, an application calls an API because a developer has already defined which operation to execute, against which system and under what conditions.
An agent can decide at runtime:
- which tool it needs,
- which API or system to query,
- which information to use,
- which sequence of actions to perform,
- whether to delegate part of the task to another agent.
This introduces an important architectural difference, the system that decides what to do and the system that authorizes and executes the action should no longer be the same.
Forrester describes the Agent Control Plane as a third functional plane alongside the build and orchestration planes, precisely because governance needs to operate outside both.
As of March 2026, Leslie Joseph, Principal Analyst at Forrester, also noted that the architecture is evolving faster than the standards needed to implement it in a fully portable way across vendors.
A five-layer framework for governing autonomous agents
For an AI Control Tower to be effective, it should not be just a console that collects information. It should be an Agent Control Plane built around five architectural capabilities.
| Layer | What it needs to address | Question it must be able to answer |
| 1. Identity and delegation | Identify the agent and limit its authority | Who is acting, and on whose behalf? |
| 2. Policy and autonomy | Decide whether an action is allowed | Can it do exactly this in this context? |
| 3. Governed execution | Intercept the action before the target system | Did the decision actually pass through the control? |
| 4. Evidence and observability | Record the decision and outcome | What was authorized, and what ultimately happened? |
| 5. Lifecycle and ownership | Manage changes, versions and owners | Who maintains this control when the agent or provider changes? |
1. Identity and delegation: the agent needs its own identity
An agent should not simply become an extension of the account of the user who initiated the task.
If an employee is allowed to review contracts, modify suppliers and approve purchases, that does not mean every agent acting on their behalf should inherit all three capabilities.
At a minimum, the model should distinguish: originating user or system → agent → delegated authority → tool → operation → resource
For example, a procurement agent could be authorized to:
- review contracts,
- check availability,
- create a draft purchase request up to a defined threshold.
But not necessarily to:
- change a supplier’s bank details,
- approve its own request,
- initiate a payment.
This requires a verifiable Non-Human Identity (NHI) for the agent and short-lived credentials scoped to the task, tool, operation and resource it needs. If one agent delegates to another, the delegation chain travels in the token and authority can only be narrowed, never expanded.
Shared technical accounts make it harder to do the opposite: attribute each action to a specific actor and enforce least privilege at a granular level.
The challenge is that there is still no mature, universal enterprise standard for carrying this agent identity across platforms.
NCCoE is studying how to apply identity and authorization standards and best practices to agents, but the work published in February 2026 is still a concept paper, although it has moved into a subsequent consultation phase since April 2026.
2. Policy and autonomy: the prompt is not a security boundary
An instruction such as “Do not modify orders above €10,000 without human approval” may be part of the agent’s expected behavior, but it should not be the mechanism protecting the ERP.
The policy that determines whether an action is allowed should exist outside the model and be evaluated before the call is executed.
A policy in the Agent Control Plane can evaluate:
- The identity of the agent and the user who originated the task.
- The requested operation and target resource.
- The risk level and classification of the data involved.
- The transaction amount or the impact on the system.
- Whether a valid human approval exists, among other contextual factors.
The outcome does not have to be limited to allow or deny either. Depending on the risk, it can be: allow → allow with constraints → simulate → request approval → quarantine → deny
OWASP specifically recommends not relying solely on model output for authorization decisions, and separating the component that decides from the component responsible for validating permissions and executing high-impact actions.
How do you decide how much autonomy to give each agent?
Not every action requires a human in the loop.
An organization can classify autonomy based on impact and reversibility:
| Level | Example | Governance |
| 0. Advisor | Recommends an action | Does not execute |
| 1. Read | Checks inventory | Read-only access |
| 2. Reversible | Creates a draft | Automatic execution + audit |
| 3. Bounded | Reschedules a delivery within defined limits | Policy and thresholds |
| 4. High impact | Changes master data or a critical operation | Approval tied to the specific action |
| 5. Prohibited | Executes an operation that is explicitly non-delegable | Denied |
The key criteria should be the potential harm an action can cause, whether it can be reversed and what authority is being delegated. In other words, this goes far beyond whether or not we trust the model. Approval must be meaningful: tied to the specific action, single-use and time-limited. If approval is granted routinely, it is not oversight.
3. Governed execution: separating who decides from who executes
This is the core of the architecture.
- The agent proposes or decides on an action.
- The control plane determines whether it may be executed.
- The execution plane carries it out.
In classic authorization terminology, the gateway or tool broker is the PEP and the policy engine is the PDP.
This separation aligns with patterns OWASP recommends for financial, administrative, destructive or other high-impact operations, as well as with the separation between control plane and execution plane described in recent agentic orchestration architectures.
Example: Policy-as-Code applied to a procurement agent
To turn this separation between decision and execution into a concrete control, consider a procurement agent requesting permission to create an operation in the ERP.
The agent can propose the action, but it does not decide whether it is authorized to execute it. Before the request reaches the enterprise system, the Agent Control Plane evaluates:
- the agent’s identity,
- its delegated authority,
- the type of operation,
- the amount,
- the risk level and,
- when required, whether a valid approval exists.
The policy follows a deny-by-default principle: every action remains denied unless a rule explicitly allows it.
Before reading the policy, it is important to establish where the attributes it evaluates come from, because the effectiveness of the control depends on it.
None of these attributes is declared by the agent itself. Identity (agent_id) and delegated authority (delegated_subject, delegation_depth, token_expiry) are derived from a verified token —with signature, issuer, audience and validity checked at the enforcement point— or from the workload’s mTLS certificate.
Business attributes (amount, currency, resource), execution context (environment, data_classification, attempt_count) and the canonical action hash (request_hash) are calculated by the gateway from the actual body of the call that is about to be executed, not from a field asserted by the agent.
A policy that evaluates data supplied by the same subject it governs is not a control; it is a suggestion.
THRESHOLD = { amount: 2000, currency: “EUR” }
WRITE_OPERATIONS = [“create”, “update”, “patch”, “delete”, “approve”, “execute”]
READ_OPERATIONS = [“read”, “get”, “list”, “search”]
PROHIBITED_OPERATIONS = [“execute_payment”]
MAX_ATTEMPTS_PER_ACTION = 2
MAX_DELEGATION_DEPTH = 2
FUNCTION evaluate_policy(request):
# 1 · Identity and delegated authority
IF agent_id IS EMPTY OR delegated_subject IS EMPTY:
RETURN DENY(“agent_identity_missing”)
IF current_time >= token_expiry:
RETURN DENY(“delegated_token_expired”)
IF delegation_depth > MAX_DELEGATION_DEPTH:
RETURN DENY(“delegation_chain_too_deep”)
# 2 · Repeated denial is a security signal, not a neutral state
IF attempt_count >= MAX_ATTEMPTS_PER_ACTION:
RETURN QUARANTINE(“policy_probing_suspected”)
# 3 · Idempotency: distinguish a legitimate retry from a replay
IF operation IN WRITE_OPERATIONS:
IF idempotency_key IS EMPTY:
RETURN DENY(“idempotency_key_required”)
IF idempotency_key HAS BEEN USED:
IF request_hash == stored_request_hash(idempotency_key):
RETURN stored_decision(idempotency_key) # legitimate retry
ELSE:
RETURN DENY(“idempotency_key_conflict”) # same key, different request
# 4 · Explicitly non-delegable operations
IF operation IN PROHIBITED_OPERATIONS:
RETURN DENY(“operation_explicitly_prohibited”)
IF resource == “supplier_bank_details” AND operation IN WRITE_OPERATIONS:
RETURN DENY(“operation_explicitly_prohibited”)
# 5 · Read-only queries, constrained by data classification
IF operation IN READ_OPERATIONS:
IF data_classification == “restricted”:
RETURN ALLOW_WITH_CONSTRAINTS(“read_restricted_data”,
[“mask_sensitive_fields”, “write_audit_event”])
RETURN ALLOW(“read_only_operation”)
# 6 · Purchase draft within the delegated limit
IF tool == “erp” AND operation == “create_purchase_draft”:
IF currency != THRESHOLD.currency:
RETURN DENY(“currency_mismatch_with_threshold”)
IF amount <= THRESHOLD.amount:
IF environment != “production”:
RETURN SIMULATE(“dry_run_outside_production”)
RETURN ALLOW_WITH_CONSTRAINTS(
“purchase_draft_within_delegated_limit”,
[“enforce_draft_only”, “record_amount_and_currency”, “write_audit_event”])
# 7 · Above threshold: human approval tied to THIS action
IF approval IS EMPTY:
RETURN REQUIRE_APPROVAL(“human_approval_required”)
IF approval IS EXPIRED:
RETURN DENY(“approval_expired”)
IF approval HAS ALREADY BEEN USED:
RETURN DENY(“approval_replay_detected”)
IF approval.action_hash != request_hash:
RETURN DENY(“approval_does_not_match_action”)
# Segregation of duties: no one approves what they originated themselves
IF approval.approver_id == delegated_subject:
RETURN DENY(“segregation_of_duties_violation”)
IF approval.approver_id == agent_id:
RETURN DENY(“self_approval_not_permitted”)
RETURN ALLOW(“exact_action_approved”)
# 8 · Deny-by-default
RETURN DENY(“no_policy_explicitly_allows_action”)
Note on request_hash. The PEP calculates the canonical hash over a fixed, ordered set of fields —agent_id, delegated_subject, tool, operation, resource, environment, amount, currency, idempotency_key— so that reordering fields or using an equivalent payload encoding cannot allow an approval granted for one action to be reused for another.
The policy returns a structured response that the gateway or tool broker must enforce before executing the call:
Policy response: allowed with constraints
{
“decision”: “allow_with_constraints”,
“decision_id”: “dec_01J8K3QF7M2A”,
“reason”: “purchase_draft_within_delegated_limit”,
“policy_version”: “purchasing-agent-v1.4.0”,
“request_hash”: “sha256:9f2c…a71e”,
“expires_at”: “2026-10-01T09:41:37Z”,
“obligations”: [
“enforce_draft_only”,
“record_amount_and_currency”,
“write_audit_event”
]
}
This example shows the separation that must exist between request, authorization and execution.
The agent proposes create_purchase_draft; the Agent Control Plane evaluates whether it may do so and under what conditions; only then does the gateway or tool broker execute the call against the ERP.
Three independent facts are recorded: the agent requested an action, the policy allowed it and the target system executed it. This does not depend on the model itself determining its permissions.
Two rules complete the design:
- First, obligations are enforceable: if the enforcement point cannot satisfy one of the obligations returned by the policy —it cannot reserve the idempotency key, force draft mode or mask a field— the decision becomes a denial.
A permission whose conditions cannot be enforced is not a permission.
- Second, the control plane operates fail-closed: if the policy engine does not respond within the agreed latency budget, the action is denied.
Decisions can be cached with a short TTL and immediate invalidation when policy_version changes, but loss of control-plane availability must never translate into unlimited autonomy.
Can the existing API Management platform be used as an Agent Control Plane?
It can be an important part of the Agent Control Plane, but it doesn’t necessarily solve the entire problem.
An API Management platform can already provide highly useful capabilities:
- authentication,
- authorization,
- policy enforcement,
- rate limiting,
- routing,
- call logging,
- backend protection,
- API contracts.
In an organization that already governs its APIs, it makes sense to reuse that control point rather than allow each agentic framework to establish direct connections to enterprise systems.
But governing agents introduces additional requirements such as agent identity, delegated authority, a tool catalog, risk-based autonomy, action-bound approval and correlation between decision and outcome.
Depending on the architecture, the API Gateway may therefore need to be complemented by:
- a policy engine (OPA, Cedar or OpenFGA),
- a tool broker,
- an identity/capability registry (Keycloak, WSO2 Identity Server),
- and an agent observability layer (OpenTelemetry).
The opportunity is to extend API Management so that actions initiated by agents follow the same governance principles as any other critical integration.
Read our new article: API Management: what it is, how it wprks and the benefits for businesses
4. Evidence and observability: record the action, not reconstruct the reasoning
How do you audit a purchase made six months ago if the agent is now running a different model version?
The answer is not to try to reproduce exactly what the model “thought.” Audit evidence should be anchored in what happened at the execution point.
For each governed invocation, it is useful to correlate:
- task identifier,
- originating actor,
- agent identity,
- agent and model version,
- requested tool and operation,
- target resource,
- policy and version evaluated,
- policy decision,
- associated approval, where applicable,
- relevant parameters, protected or anonymized where necessary,
- result returned by the target system,
- correlation identifier,
- timestamp.
There is one particularly important distinction worth making: “the policy allowed the operation” ≠ “the target system executed it successfully,” because an audit needs both events.
This makes it possible to preserve operational evidence even when the prompt, model or provider changes. The goal is to build a verifiable trace of identity, authorization, invocation and outcome.
Exporting that trace with OpenTelemetry avoids reinventing observability and connects it to the existing SIEM.
5. Lifecycle and ownership: make governance survive a change of provider
An Agent Control Plane is not finished once the first agent works.
The design should assume from the outset that the following will change:
- models,
- providers,
- agents,
- prompts,
- tools,
- MCP servers,
- APIs,
- policies,
- owners.
That is why integrations available to agents should be treated as governed capabilities with explicit contracts.
Each integrated tool should have an explicit contract defining at least:
- input/output schema and available operations,
- specific required permissions and assigned technical/business owner,
- usage limits and cost budget per agent,
- idempotency strategies for high-impact actions,
- compensation or rollback mechanisms for failures, among other elements.
Circuit breakers, versioned contracts and compatibility strategies reduce the risk that a change in one tool will trigger cascading failures.
OWASP also recommends idempotency for high-impact actions where possible, as well as explicit mechanisms for handling errors and retries.
Governance ownership must also be documented outside any specific console. A proprietary solution may implement some of these controls, but the problem arises when policies, contracts, owners and evidence exist only inside that platform.
What role does MCP play in this architecture?
The Model Context Protocol (MCP) helps standardize how an agent discovers and uses tools, but it does not replace the Agent Control Plane.
MCP facilitates agent → tool connectivity and helps avoid entirely ad hoc integrations. However, by itself it does not address:
- portable enterprise identity,
- delegated authority,
- corporate policies,
- segregation of duties,
- data governance,
- end-to-end auditing,
- autonomy decisions.
Forrester makes this point explicitly, MCP addresses agent-to-tool connectivity, while there is still no sufficiently mature agent identity descriptor that can propagate portably across the different architectural planes.
That is why an architecture designed to evolve should take advantage of emerging protocols without turning them into the place where governance lives.
How to take the model into production without transforming everything at once
Implementation can evolve in phases, so it is not advisable to start by deploying a complete enterprise AI Control Tower.
| Phase | What is done | What it enables |
| 1 · Discover | Inventory agents, technical accounts, tool calls, APIs, MCP servers and target systems. What matters is what actually runs, not what appears in the CMDB | The real scope, including agents no one had registered |
| 2 · Prioritize by risk | Route writes to ERP, IAM, payments, production, master data and sensitive information through the governed path | High-impact actions cannot bypass control |
| 3 · Delegated identity and Policy-as-Code | Replace generic permissions with a dedicated agent identity, short-lived credentials, scopes by tool and operation, and approval for higher-risk actions | Authorization sits outside the model and every action is attributable to an actor |
| 4 · Correlate authorization and execution | Build a common trace —task, agent, policy, tool call, target system, outcome— and send it to existing observability, SIEM or SOC platforms | Auditable evidence of what was authorized and what actually happened |
| 5 · Scale and transfer ownership | Extend the pattern to new agents, automate onboarding and offboarding, assign owners, add policy tests and formalize contract governance | A model that survives changes of agent, model and provider |
You may also be interested in: How AI is integrated into API Management platforms
How does this model align with NIST, OWASP and the AI Act?
These frameworks do not replace Enterprise Architecture design, but they define the boundaries within which it must operate.
- NIST AI RMF provides the risk-management structure through Govern, Map, Measure and Manage.
- OWASP provides specific controls for agentic risks such as excessive privilege, tool misuse, approval manipulation and cascading failures.
In the European Union, Regulation (EU) 2024/1689 requires high-risk systems to keep event logs and provide human oversight proportionate to the risk and degree of autonomy. The Digital Omnibus postponed those obligations to December 2027 (Annex III) and August 2028 (Annex I). Not every agent will be high-risk, but building the architecture that can demonstrate this takes longer than the time remaining.
Is your architecture ready for agents with execution capabilities?
Before expanding autonomy, an Enterprise Architect should be able to answer yes to the following questions:
- Do we have an inventory of the agents that can act on enterprise systems?
- Does each agent have its own identity and permissions?
- Can we stop an action before it reaches the target system?
- Do critical operations require specific, contextual authorization?
- Can we demonstrate separately which action was authorized and which was actually executed?
- Can we replace a model, agent or provider without rebuilding the entire governance model?
If the answer to several of these questions is no, the problem lies in the architecture connecting autonomy to execution, not necessarily in the AI model.
On June 25, 2025, Gartner predicted that more than 40% of agentic projects will be canceled before the end of 2027 due to rising costs, unclear business value or inadequate risk controls.
At Chakray, we work at the intersection of integration architecture, API Management and agentic systems.
If your organization is already connecting agents to APIs, ERP systems, data or core systems, we can help you define which controls should remain in the enterprise architecture and how to evolve the model without turning governance into a dependency on a single platform.
Frequently asked questions about Agentic Enterprise Architecture
What is Agentic Enterprise Architecture?
It is the enterprise architecture design required to integrate AI agents capable of making decisions and executing actions autonomously while maintaining identity, authorization, governance, observability and traceability across enterprise systems.
Do I need a new platform to create an Agent Control Plane?
Not necessarily. Existing API Management and identity infrastructure can provide a significant part of the control, although capabilities such as agent identity, contextual authorization, tool brokering and observability will usually need to be added or extended.
Should an agent’s policies be defined in the prompt or in the gateway?
The prompt can contain behavioral rules, but policies that protect systems and data should be enforced outside the model, in a component capable of authorizing or blocking the action before execution.
How can I audit an action if the model version changes?
By recording evidence at the point of invocation (agent identity, operation, resource, applied policy, approval, version and target-system result). This means the audit does not depend on reproducing the model’s reasoning later.
How do you decide which actions an agent can execute autonomously?
By classifying actions according to their risk, impact, reversibility and required authority. Low-impact operations can be automated, while sensitive ones can be constrained or require approval tied to the specific action.
Does MCP solve AI agent governance?
No. MCP helps standardize the connection between agents and tools, but by itself it does not address portable identity, delegated authority, corporate policies, human oversight or end-to-end auditing.
