A
Atul Kumar
Guest
Why giving AI agents access to enterprise systems is forcing organisations to rethink identity, permissions, workflows, accountability, and observability
For the last few years, much of the conversation around enterprise AI has been about whether a model is intelligent enough to answer questions, generate content, write code, summarise documents, or retrieve information from company data. That was a useful starting point, but it is becoming increasingly disconnected from what organisations are actually trying to build.
The interesting shift happens when an AI system stops being something a person talks to and starts becoming something that does work.
An agent might read a customer request, look up information in an internal system, call an API, create a record, send an email, update a workflow, ask another agent for information, and then continue operating without a person explicitly directing every individual step. At that point, the engineering problem changes. We are no longer designing only an AI interface. We are designing a new participant in the enterprise system.
This is where my thinking about AI architecture has changed the most through working with production-oriented AI systems. I initially looked at agents primarily through the lens of models, orchestration, retrieval, tools, context, and reliability. Over time, another question became impossible to ignore:
If an AI system can perform work inside an organisation, what exactly gives it the authority to perform that work?
That question connects almost everything else. Identity determines who the agent is. Permissions determine what it can access. Policy determines what is allowed to do. Observability determines whether we can understand what happened. Ownership determines who is responsible for operating it. Lifecycle management determines what happens when the agent changes, becomes inactive, or should no longer have access.
The model remains important, but it is no longer the entire engineering problem, and the industry is beginning to reflect that shift. Microsoft is now positioning Agent 365 as a control plane for observing, governing, and securing enterprise agents, with capabilities around agent registries, identity, access control, lifecycle management, auditing, and observability. Google Cloud's agent platform similarly includes agent identity, an agent registry, an agent gateway, governance controls, topology, and observability.[Ref]
That tells me something important: the next stage of enterprise AI is not simply about building better agents. It is about building the architecture around agents.
The moment an AI stops answering and starts acting
There is a fundamental difference between an AI assistant answering a question and an AI agent acting. Suppose an employee asks: "What is the status of this customer's order?"
The system retrieves information and produces an answer. If the answer is wrong, the immediate consequence may be a bad decision by the employee.
Now change the request: "Check the order, identify the problem, contact the customer, create a support ticket, and issue a replacement if the eligibility rules are satisfied."
That is no longer simply information retrieval; the system is now interacting with the enterprise state. It may need access to a customer database, order-management system, support platform, email service, financial rules, inventory data, and perhaps another AI service. It needs to decide which tools to call and in what order. It needs to preserve state across multiple operations. It needs to understand which actions require approval and which can happen automatically.
Most importantly, every action creates consequences. This is the point where I believe the language around "AI assistants" becomes inadequate. The architecture starts looking much more like the architecture of an organisational worker or software service than a conventional chatbot. The agent needs a recognisable identity. It needs defined responsibilities. It needs access boundaries. It needs a lifecycle. It needs monitoring. It needs an owner, and it needs a way for the organisation to say: This agent is allowed to do this, but not that.
An agent needs an organisational identity
One of the simplest mistakes an organisation can make is treating an AI agent as an anonymous process. Traditional applications already have identities. Services have service accounts. Applications have credentials. Users have accounts. Machines have identities. APIs have authentication mechanisms.
If an agent is going to perform meaningful work, it needs the same architectural treatment. Imagine an agent called
customer-resolution-agent.It might have permission to:
- read order information,
- read customer support history,
- create support tickets,
- send predefined customer communications,
- request a replacement,
- and access specific inventory information.
It should not automatically have permission to:
- export the entire customer database,
- access payroll,
- modify financial records,
- delete customer accounts,
- or call arbitrary external services.
The distinction is important because the agent's intelligence does not define its authority. A highly capable agent should not automatically receive highly privileged access. This is one of the areas where enterprise identity systems are now evolving. Microsoft's current Agent 365 documentation describes purpose-built agent identities and the use of Microsoft Entra controls to authenticate, authorise, monitor, and govern agents. Google Cloud similarly describes per-agent identities designed around least-privilege access and lifecycle management. [Ref]
The architecture, therefore, starts looking something like this:
Code:
HUMAN / BUSINESS OWNER
│
▼
AGENT IDENTITY
│
┌──────────┴──────────┐
│ │
▼ ▼
POLICY AUTHORITY
│ │
└──────────┬──────────┘
▼
AI AGENT
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
APIs TOOLS DATA
│ │ │
└────────────────┼────────────────┘
▼
BUSINESS ACTION
│
▼
AUDIT + OBSERVABILITY
│
▼
HUMAN ACCOUNTABILITYThe important part of this architecture is not the model. It is the chain of authority surrounding the model.
Permissions are not the same thing as capability
This distinction became particularly important as I started thinking about agents as production systems rather than conversational interfaces. A model can technically call a tool without necessarily being authorised to use that tool for every situation. For example, an agent may have access to a payment API because its workflow sometimes requires payment processing. That does not mean it should be able to initiate any payment it chooses.
Capability answers: Can the system technically perform this operation?
Authorisation answers: Is the system permitted to perform this operation under these circumstances?
Those are different questions. A production architecture should therefore avoid giving an agent a large collection of unrestricted tools and trusting the model to decide when they are appropriate. Instead, the system should establish explicit boundaries. A simplified policy might look like this:
Code:
agent:
name: customer-resolution-agent
permissions:
read:
- orders
- customer_support
- inventory
write:
- support_ticket
- customer_notification
conditional:
replacement_order:
requires:
- order_status == "eligible"
- replacement_value < 500
approval:
above: 500
denied:
- payroll
- employee_records
- customer_database_exportThe exact implementation will vary between organisations, but the principle is broadly applicable. The model should not be the final enforcement point. The runtime architecture should enforce the policy. This is also why agent gateways and centralised policy enforcement are becoming important. Google Cloud's current documentation describes Agent Gateway as a runtime enforcement point that manages agent traffic and applies access-control policies to interactions with tools and other agents [Ref]. That is a significant architectural idea, and instead of asking the model to behave correctly every time, we create infrastructure that limits what the model can actually do.
The enterprise cannot rely on the prompt as the security boundary
This is one of the lessons that became increasingly obvious to me as I worked through AI system design. A prompt can describe rules. It cannot be the only mechanism enforcing those rules. Consider an instruction such as: "Never expose confidential customer information."
That sounds reasonable, but what happens if confidential information enters the context through a document, tool response, retrieval result, or another agent?
What happens if a malicious instruction is embedded inside the retrieved content?
What happens if an external website tells the agent to perform an action that conflicts with organisational policy?
The system cannot simply assume that every piece of text entering the context is trustworthy. The architecture needs separate enforcement layers.
Code:
USER REQUEST
│
▼
IDENTITY
│
▼
POLICY CHECK
│
▼
AGENT
│
▼
CONTEXT / RETRIEVAL
│
▼
TOOL REQUEST
│
▼
AUTHORIZATION
│
▼
TOOL EXECUTION
│
▼
RESULT VALIDATION
│
▼
AUDIT + OBSERVABILITYThe model can reason about the task, but the infrastructure should decide whether the requested action is permitted. This separation becomes especially important when agents have access to systems containing sensitive business information.
Who owns an agent's decisions?
Identity solves only part of the problem. The next question is ownership. Imagine that an organisation has 500 agents.
Some were built by engineering teams. Some were created by business units. Some came from vendors. Some were developed by individual employees for internal workflows. Some are temporary experiments that became useful enough to remain in production.
Now imagine one of those agents makes an incorrect decision. Who owns it? The answer cannot simply be "the person who typed the prompt."
The organisation needs to know:
- Who created the agent?
- Who approved its deployment?
- Who owns the business process?
- Who approved its permissions?
- Which version of the agent was running?
- Which model was used?
- Which tools did it call?
- Which data did it access?
- What policies were active?
- Who can disable it?
- Who reviews its access?
- Who is responsible when its behaviour changes?
This is why agent ownership needs to become part of architecture rather than an administrative afterthought. Microsoft's current identity-governance documentation describes human sponsorship for agent identities, including accountability for an agent's purpose, lifecycle decisions, and access reviews. [Ref]
That concept is particularly important because AI systems are not static applications. Their behaviour can change when the model changes, prompts change, retrieval changes, tools change, policies change, or the surrounding data changes.
An agent that was safe last month may behave differently after a significant update. Ownership, therefore, needs to remain active throughout the agent's lifecycle.
The new architecture of work
If agents become participants in enterprise workflows, the architecture of work starts changing. A traditional enterprise workflow might look like this:
Code:
Employee
│
▼
Application
│
▼
Business Process
│
▼
Database / APIAn agentic workflow can look more like:
Code:
Employee
│
▼
AI Agent
│
├────► Agent A
│
├────► Agent B
│
├────► Internal API
│
├────► External API
│
├────► Knowledge Base
│
└────► Enterprise DatabaseThe number of possible interactions grows quickly. The architecture becomes a graph rather than a simple request-response pipeline, and that graph introduces new failure modes.
An agent may call another agent who calls a tool. The tool may access a database. The database may return stale information. Another agent may make a decision based on that result. Meanwhile, the underlying business state may have changed, and this is not fundamentally different from distributed systems engineering.
It is distributed systems engineering with probabilistic decision-making in the middle, and that distinction matters because many of the reliability principles we already understand become even more important.
Timeouts, Idempotency, Authorisation, Versioning, Transactions, Observability and State management matters. The AI does not remove those engineering problems. It adds another layer of complexity to them.
Why traditional RBAC is not enough by itself
Role-based access control is useful, but agents introduce situations where static roles may not provide enough context. Consider an employee who has permission to approve expenses up to ₹100,000. Should their AI agent automatically inherit the same authority? Not necessarily.
The agent may need additional constraints:
- Which expense categories can it approve?
- Can it approve its owner's own expenses?
- Can it approve expenses outside business hours?
- Can it approve recurring payments?
- What happens if the amount exceeds a threshold?
- What if the supporting documentation is incomplete?
- What if the request involves a restricted vendor?
This is where authorisation starts becoming contextual. A more complete policy might consider:
Code:
WHO
↓
Which agent?
WHAT
↓
Which action?
ON WHAT
↓
Which resource?
UNDER WHICH CONDITIONS
↓
Amount, risk, data sensitivity, workflow state
FOR HOW LONG
↓
Time-bound authorization
WITH WHAT OVERSIGHT
↓
Human approval / automated policy / monitoringThis model moves beyond simply asking whether an agent belongs to a role. It asks whether a particular action is appropriate at this moment, against this resource, under these conditions. That is much closer to how high-value enterprise automation needs to work.
Not every decision should be autonomous
One of the most important architectural choices is deciding where autonomy should stop. There is a tendency in agentic AI discussions to treat human involvement as a temporary limitation. I think that is too simplistic. Human approval is not always a sign that the system failed to automate something. Sometimes it is an intentional control boundary.
For example, an agent could automatically:
- classify an incoming request,
- collect relevant information,
- verify eligibility,
- prepare a response,
- calculate a recommendation,
- and create a proposed action.
But the final action might require a human when the financial, legal, security, or operational consequences cross a defined threshold. The architecture could therefore look like:
Code:
AI AGENT
│
┌─────────┴─────────┐
│ │
LOW-RISK HIGH-RISK
ACTION ACTION
│ │
▼ ▼
AUTOMATICALLY HUMAN APPROVAL
EXECUTE │
│ ▼
│ AUTHORIZED ACTION
│ │
└─────────┬─────────┘
▼
AUDIT + TELEMETRYThe interesting part is that the threshold does not have to be based only on the type of action. It can also depend on uncertainty, data sensitivity, financial value, business impact, or the agent's confidence in the underlying information.
This creates a more practical definition of autonomy. Autonomy is not simply "the AI can do everything." It is the AI can operate independently within a clearly defined authority boundary.
Observability has to capture decisions, not just logs
This is another area where my view of AI observability has changed. Traditional application monitoring asks questions such as:
- Did the service respond?
- How long did it take?
- Did the API return an error?
- How many requests failed?
Those metrics remain important, but they are insufficient for agentic systems. Imagine an agent completes a workflow successfully.
HTTP status:
200Latency:
1.8 secondsNo infrastructure errors.
From a conventional monitoring dashboard, everything looks healthy. But the agent used the wrong customer record. The system may have executed exactly as designed and still produced the wrong business outcome. That means observability needs to follow the decision path.
Code:
Request
│
├── Identity
│
├── Policy evaluation
│
├── Model
│
├── Retrieved context
│
├── Tool selection
│
├── Tool execution
│
├── External response
│
├── Agent decision
│
├── Final action
│
└── OutcomeWhen something goes wrong, I want to be able to reconstruct that chain.
What did the agent know?
What information did it retrieve?
Which tool did it select?
What authorisation decision was made?
What data did the tool return?
Which model version generated the decision?
Which policy was active?
What action was finally executed?
Google Cloud's current agent platform documentation reflects this direction by connecting agent identity, gateway controls, traces, logs, metrics, topology, and evaluation. This is much closer to forensic observability than simple application monitoring.
Multiple agents create a second-order problem
One agent is already complicated. Multiple agents introduce another layer. Imagine:
Code:
ORCHESTRATOR
│
┌────────────┼────────────┐
▼ ▼ ▼
RESEARCH FINANCE OPERATIONS
AGENT AGENT AGENT
│ │ │
▼ ▼ ▼
APIs ERP Inventory
│ │ │
└────────────┼──────────────┘
▼
FINAL ACTIONNow consider what happens when the agents have different permissions, different data sources, different versions, and different objectives.
The research agent may discover information that the finance agent is not authorised to access.
The finance agent may make a recommendation based on data that the operations agent cannot verify.
The orchestrator may combine all of these outputs without fully understanding their provenance.
The system now has an authority graph as well as a data graph.
That is something enterprises will increasingly need to model. It is not enough to know that Agent A can call Agent B. We need to know: Why can Agent A call Agent B, under whose authority, with which permissions, using what data, and with what consequences?
That is where centralised registries and topology views become useful. Microsoft describes an agent registry and agent map for understanding agents and their connections, while Google describes centralised registries and topology graphs for agents, endpoints, and MCP servers.
The agent lifecycle becomes part of enterprise architecture
Another problem I expect organisations to encounter is what I would call agent sprawl. Creating an agent can be remarkably easy. Managing hundreds or thousands of agents is not. An enterprise needs to think about an agent's complete lifecycle:
Code:
CREATE
│
▼
REGISTER
│
▼
IDENTITY
│
▼
APPROVE
│
▼
DEPLOY
│
▼
MONITOR
│
▼
REVIEW
│
▼
UPDATE
│
▼
SUSPEND / RETIREEach stage has different requirements.
During creation, the organisation needs to understand the purpose of the agent. During registration, it needs to establish identity and ownership. Before deployment, permissions and policies need to be evaluated. During operation, behaviour and performance need to be monitored. During updates, changes to models, tools, prompts, policies, or data dependencies need to be evaluated.
When the agent is retired, its credentials and access need to be revoked. This may sound like ordinary application lifecycle management. But the difference is that agent behaviour is often more dynamic. An agent can adapt its path through a workflow based on context. That makes lifecycle governance especially important.
Microsoft's current Agent 365 architecture explicitly includes lifecycle management, including controls around inactive, ownerless, and risky agents.[Ref]
The control plane is becoming as important as the agent
This is probably the architectural conclusion I keep coming back to. For years, we focused on the application. Then we built platforms around applications. Now we are starting to need platforms around agents. The architecture begins to look like:
Code:
┌───────────────────────────────┐
│ AGENT CONTROL PLANE │
│ │
│ Identity │
│ Policy │
│ Registry │
│ Permissions │
│ Security │
│ Observability │
│ Audit │
│ Lifecycle │
│ Evaluation │
│ Cost │
└───────────────┬───────────────┘
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
Agent A Agent B Agent C
│ │ │
└─────────────────┼─────────────────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
APIs Data Tools
│ │ │
└────────────┼────────────┘
▼
ENTERPRISE SYSTEMSThe control plane does not replace the agents. It makes them manageable, and that distinction is important.
I don't think the future enterprise will have one giant AI system making every decision. It is more likely to have many specialised agents operating within different business processes, connected to different systems, with different authorities and responsibilities. The challenge will therefore be coordinating them without losing visibility or control.
What I would design differently today
If I were designing a production AI agent architecture today, I would start with the authority model before starting with the prompt. I would first define what the agent is responsible for and what it is explicitly not responsible for. I would give it an identifiable owner and a dedicated identity. I would define the resources it can access and make those permissions as narrow as practical.
Then I would design the workflow around policy enforcement rather than trusting the model to follow instructions. The model would be responsible for reasoning and selecting appropriate actions within the available capabilities. The infrastructure would remain responsible for authentication, authorisation, policy enforcement, validation, auditing, and execution boundaries.
I would also make observability part of the architecture from the beginning rather than adding dashboards after deployment. For every meaningful action, I would want to answer:
Code:
Who initiated this?
Which agent acted?
Which identity did it use?
What context did it receive?
Which policy applied?
Which tools were called?
What data was accessed?
What decision was produced?
What action was executed?
What was the outcome?If those questions cannot be answered, the system is not yet operationally mature enough for high-impact autonomous work. I would also separate low-risk automation from high-impact actions and establish explicit approval boundaries. Finally, I would treat agents as lifecycle-managed infrastructure rather than permanent scripts.
An agent should have a creation date, owner, version, identity, permissions, dependencies, monitoring, review process, and retirement mechanism. That sounds less exciting than talking about autonomous intelligence. But in production, these details are where reliability comes from.
The enterprise will have to manage AI differently
The more I work through these architectures, the less I think the central question is whether AI agents will replace particular categories of software or workers. The more immediate engineering question is how organisations will integrate systems that can reason, use tools, maintain state, and perform actions into environments that were designed around predictable software and accountable humans. That requires a change in architecture.
An employee, an application, and a service have an identity.
An AI agent that can access enterprise systems should not be treated as an exception. It should have one too.
An employee, application, or service has permissions.
Agents need permissions that are explicit, scoped, reviewable, and revocable.
Employees, applications operate within organisational policies.
Agents need policy boundaries that are enforceable by infrastructure rather than merely described in prompts, and when something goes wrong, an organisation needs to reconstruct what happened. That means identity, policy, observability, and auditability cannot remain separate concerns. They become part of the AI architecture itself.
AI agents are not just another software feature
This is probably the biggest lesson I have taken from working on production-oriented AI systems. When an AI system only generates text, the architecture can often hide a lot of complexity behind an interface.
Once the AI starts acting, that complexity becomes visible. The system needs to understand the state.
It needs to manage context, authenticate, authorise, call tools, handle failures, deal with changing data, produce traceable decisions, respect organisational policies and answer a very human question: Who is accountable for what it did?
That is why I think the next phase of enterprise AI engineering will be less about building increasingly impressive demonstrations and more about building the infrastructure that makes autonomous systems trustworthy enough to operate continuously.
The model will continue to improve, the agents will become more capable, the number of tools available to them will increase, and organisations will deploy more of them. But capability without an authority model creates a system that can act without a sufficiently clear understanding of where its authority begins and ends.
The real engineering opportunity is therefore not simply to create agents that can do more. It is to create enterprises where agents can do the right amount of work, with the right authority, under the right policies, with the right level of oversight.
That is a much harder problem than building another chatbot, and, in my view, it is also where some of the most interesting AI engineering work is beginning.
Reference architecture
Putting the entire idea together, the architecture I would use as a mental model is:
Code:
┌─────────────────────┐
│ BUSINESS OWNER │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ AGENT IDENTITY │
│ Owner / Sponsor │
│ Credentials │
└──────────┬──────────┘
│
┌───────────────┼────────────────┐
▼ ▼ ▼
┌─────────┐ ┌──────────┐ ┌───────────┐
│ POLICY │ │ PERMISSION│ │ LIFECYCLE │
│ ENGINE │ │ ENGINE │ │ MANAGEMENT│
└────┬────┘ └────┬─────┘ └─────┬─────┘
│ │ │
└──────────────┼─────────────────┘
▼
┌─────────────────────┐
│ AI AGENT │
│ Reasoning / Planning│
│ Context / Memory │
└──────────┬──────────┘
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
┌───────┐ ┌───────┐ ┌───────┐
│ TOOLS │ │ APIs │ │ DATA │
└───┬───┘ └───┬───┘ └───┬───┘
│ │ │
└─────────────────┼─────────────────┘
▼
┌─────────────────────┐
│ EXECUTION BOUNDARY │
│ Validation / Policy │
│ Approval / Controls │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ BUSINESS ACTION │
└──────────┬──────────┘
│
▼
┌─────────────────────────────────────────┐
│ OBSERVABILITY + AUDIT │
│ Traces | Decisions | Tools | Data │
│ Policies | Outcomes | Cost | Errors │
└─────────────────────────────────────────┘The architectural shift is straightforward to describe but difficult to implement: the agent should not be the control plane. The agent operates inside the control plane, and as AI moves deeper into enterprise workflows, that distinction may become one of the most important design principles in AI engineering.