AI does not make identity optional
An agent with privileged access but no attributable identity is a service account with a generated personality.
Once an AI agent can take action in enterprise applications, the architecture must consistently answer three questions: Who is it acting as? What is it allowed to do? What did it do? These are not abstract governance questions. They determine whether an agentic system can be operated safely at enterprise scale.
The answer to the first question is not always a person. Some actions begin with an authenticated user. Others begin with a scheduled process, an application event, or another workload. A third category emerges when one agent delegates work to another. Enterprise architecture, therefore, needs to distinguish between user identity, workload identity, and delegated identity rather than treating every agent action as though it originated from the same kind of principal.
This matters because an agentic transaction may pass through several layers before anything changes in a system of record. A request may begin with a person, pass through a generalist Genie, be delegated to a specialist Genie, invoke an MCP capability, execute through a recipe, and finally reach a backend application. The architecture must preserve that chain of authority rather than collapse the entire transaction into whichever credential reaches the final system.
A shared credential can unlock the door. It cannot tell you opened and walked through it.
There are legitimate uses for shared or workload credentials. A scheduled process may run without an individual actively signed in, and a development environment may use a shared credential when testing a connection. But when a user-facing experience initiates a consequential action, the originating identity should not disappear simply because the request crossed into an AI interface.
This is where mechanisms such as Verified User Access become part of the architecture rather than implementation details. Where user-level execution is appropriate, the initiating person’s authority can be preserved via the mediated path, allowing the backend application to continue enforcing the permissions associated with that person. Where the action belongs to a workload instead, the system should represent that workload explicitly rather than pretending that a human initiated it.
Identity is therefore not simply about authentication at the front door. It is about preserving attributable authority throughout execution.
Platform access != business permission
An administrator should not accidentally become an all-powerful agent user.
Authentication establishes who or what is making a request. Authorisation determines what that identity is permitted to do. Those responsibilities must remain separate. A person’s ability to administer an integration or AI platform should not automatically permit them to invoke every business capability exposed through it.
The same principle becomes more important as agents collaborate. A task handoff should not become a permission handoff. When one Genie delegates bounded work to another, the receiving Genie should not inherit unlimited authority simply because another agent called it. Each delegation still needs to be evaluated against the identities involved, the authority being delegated, the target capability, and the applicable backend policy.
This is especially important when specialist Genies themselves represent reusable enterprise capabilities. The fact that a specialist Genie knows how to complete a task does not mean every caller should be allowed to ask it to do so. Capability reuse and authorisation are complementary ideas: a capability should be reusable across authorised consumers precisely because its access is consistently governed.
Risk should also be evaluated according to business impact rather than on simple technical categories. Read and write capabilities often have different risk profiles, but a read operation that exposes payroll, customer, or regulated data may be more consequential than a low-impact write. Authorisation, therefore, needs to reflect the capability’s blast radius, the data’s sensitivity, the caller’s authority, and the effect of the resulting action.
Do not confuse the ability to act with the authority to act.
If you cannot trace it, you cannot trust it
If you cannot prove what an agent did, you have deployed an audit gap.
Authentication and authorisation establish who is permitted to initiate an action. They do not, by themselves, tell the enterprise what happened after execution began. A production-grade agentic architecture must connect the initiating identity, the capability invoked, the execution path, and the resulting backend action into a trace that can be reconstructed later.
That trace becomes more important as the path becomes more mediated. A user may interact with one Genie, which delegates to another Genie, which invokes an MCP capability backed by a recipe, which then interacts with multiple enterprise applications. The fact that several components participated should not break the chain of attribution.
In Workato, the control plane and execution environment can provide connected layers of evidence across that path. Server-level activity can record the identity, authentication method, source, tool, permitted request metadata, execution timing, and result. The resulting tool invocation can be associated with recipe execution, and that execution record can show what happened across the underlying applications. Sensitive inputs and outputs should be handled with appropriate masking, redaction, access, and retention controls rather than indiscriminately captured simply because logging is technically possible.
This changes the questions the enterprise can answer. Security should be able to determine which capabilities a particular identity accessed. Operations should be able to establish whether the requested work was completed, failed, or partially executed. Compliance should be able to connect an initiating user or workload to the capability invocation, workflow execution, and resulting backend action.
The more valuable an agent becomes, the less acceptable it is for its actions to be opaque.
Guardrails limit blast radius
A rate limit is not bureaucracy. It is blast-radius control.
Identity, authorisation and traceability establish who can act and what can be reconstructed afterwards. Enterprise AI needs controls over how much an authorised actor can do, how quickly it can do it, and under what operating conditions. Rate limits, quotas, network restrictions, end-user groups, capability-specific policies, and administrative controls all help constrain the effect of unexpected behaviour.
These controls should follow the architecture of the capability rather than being applied as generic decoration. Authentication methods should match the use case. Users and workloads should belong to appropriate groups. Verified User Access should be used where a capability must preserve the initiating user’s downstream permissions and attribution, particularly for sensitive or regulated actions. Higher-impact capabilities may warrant stronger access controls, additional approvals, lower rate limits, or more restrictive operating conditions.
Governance also needs its own audit trail. Changes to capability access, server configuration, policies, authentication methods, and administrative settings should be observable just as execution is observable. Governance is not a document created after deployment. It is a continuously operated part of the system.
But guardrails cannot repair a bad execution architecture. A quota can stop an inefficient process from running indefinitely, but it cannot make that process efficient. A rate limit can contain the impact of an unexpected action. Still, it cannot compensate for an architecture that repeatedly asks a model to rediscover deterministic work the enterprise already knows how to perform.
Guardrails contain risk. Good architecture removes unnecessary risk at the source.
Control and execution belong together
Authorisation without reliable execution is incomplete. Execution without accountability is unsafe.
The control plane must govern more than whether a request is allowed to cross the front door. In Workato, that control can extend through the execution path: the client is authenticated, access to the capability is authorised, the appropriate user or workload identity is carried into execution, the governed capability performs the business process, backend permissions are applied, and execution records connect the resulting activity across the path.
This is important because control and execution are not separate enterprise concerns. The same capability that is reusable across MCP clients, Genies, recipes, events, and people must also operate under the correct identity, authorisation, policies, approvals, recovery behaviour, and observability. Otherwise, the enterprise has either reliable automation without accountability or sophisticated access control around execution that it cannot reliably complete.
Parts 1 and 2 of this series argued for reusable enterprise capabilities and for placing AI reasoning only where uncertainty genuinely requires it. Part 3 completes that architecture by adding authority and accountability. Reuse determines what the enterprise exposes. Orchestration determines how work is coordinated. The control plane determines under whose authority the work occurs and whether the enterprise can prove what happened.
The role of enterprise architecture is therefore not simply to make more things possible. It is to determine which capabilities should exist, who and what may invoke them, which authority should survive through delegation, where additional controls are required, and what evidence must remain after execution.
The goal is not to put AI everywhere. It is to make intelligent action possible where it creates value, while ensuring that the capabilities agents use remain reusable and every resulting action remains governed and accountable.
Everything may be technically possible. Architecture determines what is permissible.