Why Enterprise AI Agents Need Identity, Permissions and Runtime Governance
By Murray Newlands
The first phase of enterprise AI was about access to models. The second phase was about productivity. The next phase is about control.
AI agents are no longer just drafting text, summarizing meetings or answering questions. They are beginning to take actions. They read documents, call tools, update records, send messages, move data between systems and trigger workflows.
That changes the risk profile.
A chatbot can be wrong. An agent can do something wrong.
That distinction is why AI agent governance is becoming one of the most important enterprise AI topics for CEOs, CFOs, CISOs, CTOs and boards. The issue is not whether companies will use agents. They already are. The issue is whether they can see them, govern them and trust them once those agents start operating inside real business systems.
At Open Future Forum dinners, this is now a recurring executive conversation. Leaders are not only asking whether AI agents are powerful. They are asking what happens when agents have access to company data, customer records, internal tools, credentials and workflows. They are asking who is accountable when an agent acts. They are asking whether existing identity, security and governance systems were designed for this new kind of actor.
That is the real enterprise AI question.
An AI agent is not quite an employee, not quite an application and not quite a chatbot. It is a software actor that can reason, choose tools and act repeatedly on behalf of a user or company. That means the agent era requires a different control model.
Companies Need an Inventory of Their Agents
The first problem is basic visibility.
Many companies do not know how many agents they already have running. Some were built by engineering teams. Some were added through SaaS tools. Some were created in low-code or no-code environments by business users. Some are embedded inside workflows that started as automation and slowly became more autonomous.
This creates a hidden estate of non-human actors. Each may have access to tools, APIs, documents or customer data. Each may be using credentials. Each may be taking actions that are hard to trace later.
Before an enterprise can govern agents, it has to know they exist.
An agent inventory should answer several basic questions:
- Which AI agents are running?
- Who owns each agent?
- Which systems can each agent access?
- Which users can each agent act for?
- What credentials or tokens does each agent use?
- What actions has each agent taken?
- Can access be revoked for one agent without disrupting others?
This sounds operational, but it is strategic. The companies that can scale agents safely will not be the companies with the most experiments. They will be the companies with the clearest inventory, the strongest controls and the best audit trail.
OAuth Is a Foundation, Not a Complete Agent Security Model
OAuth remains an important foundation for delegated access. It solved a real problem for web applications: allowing one application to access another service without sharing a password.
But AI agents stress OAuth in new ways.
OAuth was built around a human approving an application. An agent is different. It may act many times, across many systems, long after the original approval. It may operate in the background. It may act for many users. It may interpret instructions incorrectly. It may believe it has permission to do something that was never intended.
That is why “the agent uses OAuth” is not enough as a security answer.
The more precise questions are:
- Does each agent have its own identity?
- Are permissions enforced at runtime?
- Are scopes narrow enough for autonomous behavior?
- Can the company distinguish between the human user and the agent acting for that user?
- Can a single agent’s access be revoked immediately?
- Can the company prove what the agent actually did?
OAuth gets the agent through the front door. It does not, by itself, answer every question about what the agent should be allowed to do once inside.
Credentials Should Not Sit Inside Agents
One of the least discussed risks in agentic AI is credential sprawl.
An agent that needs to access Slack, Google Drive, Salesforce, GitHub, an internal database or a customer system needs some form of credential. In early prototypes, those credentials often end up in environment files, local configs, repositories or databases.
That may work for a demo. It is dangerous in production.
Agents should not hold raw, long-lived secrets. They should not carry broad user tokens. They should not rely on shared service accounts that make attribution impossible.
The better model is to treat credentials as infrastructure. A controlled layer should hold the credential, issue short-lived access, scope that access to the task, trace every use, rotate tokens and revoke access in one step.
This matters most when something goes wrong. If a token leaks or an agent misbehaves, leadership should not have to ask engineers to search through code, configs and old systems to work out what still has access. The company should already know.
AI Governance Has to Move From Policy to Runtime
Most enterprises now have AI policies. That is progress, but a policy document does not govern an agent.
Governance happens at the moment of action.
A policy might say an agent should only access customer data when acting for an authorized user. The real control is whether the system enforces that rule when the agent reaches for the data.
That is the shift from written governance to runtime governance.
Runtime governance asks, in the moment:
- Which agent is acting?
- Which user is it acting for?
- What action is it trying to take?
- Which system or data source is involved?
- Is this action allowed?
- Does this action require human approval?
- Will the decision and action be logged?
This is where the enterprise AI conversation becomes more serious. It is not enough to say agents should follow policy. The policy has to become a control that is enforced where agents actually act.
For regulated industries, this becomes even more important. Record-keeping, human oversight, transparency and auditability cannot be reconstructed reliably after the fact. They have to be built into the way agents operate.
The Real Cost of an Uncontrolled Agent
The visible cost of an uncontrolled AI agent is whatever it breaks. It may send the wrong message, update the wrong record, expose the wrong data, delete the wrong file or trigger the wrong workflow.
But the larger cost usually comes after the incident.
There is the investigation. What happened? Which systems were touched? Which customers were affected? Which credentials were used? What else might have been exposed?
There is the compliance cost. If the company cannot prove what the agent did and did not do, the incident becomes harder to explain to auditors, regulators, customers and internal leadership.
There is the cleanup cost. Bad CRM data, wrong customer communications, leaked credentials and broken workflows all create downstream work.
Then there is the cost that rarely appears in the incident report: lost momentum. After a serious agent failure, leadership often slows or freezes AI deployment. The company becomes more cautious. Internal trust falls. Competitors that built stronger controls from the beginning keep moving.
That is why AI agent control is not anti-innovation. It is what allows innovation to continue.
Hallucination Is Different When Agents Can Act
In the chatbot era, hallucination usually meant an incorrect answer. In the agent era, hallucination can become an incorrect action.
An agent may misunderstand a request. It may invent a tool call. It may believe it has access it does not have. It may treat an uncertain assumption as fact. It may write a false conclusion into memory. It may proceed with confidence when it should escalate.
No serious enterprise strategy should depend on eliminating hallucination entirely. The more practical strategy is containment.
That means companies need:
- Confidence thresholds.
- Tool-call validation.
- Runtime permission checks.
- Human approval gates for high-risk actions.
- Audit logs that show what happened.
The goal is not to pretend agents will never be wrong. The goal is to make sure that when they are wrong, the damage is limited, visible and correctable.
Context Is a New Security Boundary
As companies move from single agents to multi-agent systems, context becomes one of the most important control surfaces.
Agents increasingly pass information to other agents. They share summaries, tool outputs, documents, intermediate reasoning, customer records and workflow state. That context may contain sensitive data, hidden instructions, credentials, regulated information or misleading content.
In multi-agent systems, a failure may not happen in one obvious place. One agent may retrieve poisoned content. Another may summarize it. A third may act on it. Each step can look harmless in isolation while the chain creates risk.
That is why companies need a principle of least context. Each agent should receive only the information required for its task, no more.
Safe context sharing requires:
- Redaction before sensitive data enters the model context.
- Source labels that distinguish trusted instructions from untrusted content.
- Sensitivity labels for data.
- Provenance on agent-to-agent handoffs.
- Logs of what context was accessed and shared.
The enterprise question is no longer only who can access a database. It is also which agent can pass which context to which other agent under which conditions.
Centralized or Decentralized Agents? The Better Question Is Control
There is a legitimate debate about whether agent systems should be centralized or decentralized. Some use a central orchestrator. Some use specialized agents that coordinate directly. Many will use hybrid architectures.
The architecture should depend on the work. A complex report may need a central planner. A large document processing task may benefit from distributed agents. Different workloads will require different patterns.
But the control plane should not be scattered.
Execution can be decentralized. Governance should be centralized.
No matter how agents are arranged, the company needs one consistent way to manage identity, permissions, credentials and auditability. Otherwise, decentralized execution becomes decentralized risk.
This is especially important with agent swarms. Each agent may have a narrow role, but several agents acting together may create a broader capability than anyone intended. One agent reads customer data, another writes to a shared file, and a third sends the file externally. No single agent appears to have full exfiltration capability, but the chain does.
Central governance is how the company sees and controls the chain.
Cost and Latency Are Also Governance Issues
AI agent cost is often discussed as a model pricing problem. In practice, it is often a control problem.
Uncontrolled agents call tools unnecessarily, retrieve too much context, repeat work, loop through planning steps and run without quotas. A single user request may become a dozen model calls and multiple tool calls. At scale, that becomes expensive and slow.
The solution is not simply to use cheaper models everywhere. That can reduce quality. The better approach is to understand where expensive reasoning actually matters.
Companies can reduce cost and latency through:
- Model mixing, using cheaper models for lower-risk steps and stronger models for higher-risk decisions.
- Lazy evaluation, avoiding work until it is actually needed.
- Reasoning caches, so agents do not solve the same subproblem repeatedly.
- Tool output compression, so models are not overloaded with unnecessary context.
- Runtime budgets and quotas, so runaway loops hit a limit.
The same visibility that helps security teams understand agent behavior also helps finance and engineering teams understand agent cost. Per-agent, per-action observability is the foundation for both governance and efficiency.
Agent Personality Is Not Just Tone
There is also a softer but important layer: how agents present themselves.
In an enterprise setting, “personality” is probably the wrong word. The better term is role definition. What is this agent for? How should it speak? What should it refuse? When should it escalate? How should it disclose that it is an AI system? What authority does it have?
This matters because users calibrate trust based on how an agent behaves. A confident, warm or authoritative agent can create over-trust. A hyper-agreeable agent may validate bad assumptions. A poorly defined agent may imply authority it does not actually have.
The important principle is that the agent’s role must never exceed its permissions.
An agent may sound helpful, but it should not be able to approve actions outside its grant. It may sound confident, but it should still escalate when the risk requires it. It may appear capable, but the infrastructure underneath should define what it can actually do.
Memory Writes Deserve Special Control
Long-running agents become more useful when they can remember. They can retain preferences, workflow history, customer context and prior decisions.
But memory also introduces a new failure mode.
A wrong answer may disappear after one interaction. A wrong memory can persist. It can shape future behavior, compound over time and quietly move the agent away from reality.
That is why memory writes should be treated differently from memory reads. Reads can be frequent. Writes should be deliberate, validated and reversible.
For production agents, companies should ask:
- What is the agent allowed to remember?
- Who approved the memory write?
- What source supports the memory?
- Can the memory be corrected or deleted?
- Is there a log of when and why the memory changed?
Agent memory is not just a user experience feature. It is part of the governance surface.
Agentic AI Needs a Control Layer
All of these issues point in the same direction. Agentic AI needs a control layer built for non-human actors that reason and act.
That layer has to answer the questions existing systems were not fully designed to answer:
- Which agent acted?
- Which user was it acting for?
- What was it allowed to do?
- Which credential did it use?
- What context did it receive?
- What tools did it call?
- What did it change?
- Was human approval required?
- Can the company prove all of this later?
This is the category where companies such as Agentic Fabriq are emerging: identity, permissioning and governance for AI agents. I advise Agentic Fabriq, which has given me a closer view of how quickly this problem is moving from technical edge case to board-level infrastructure question.
The shorthand some people use for this category is “Okta for agents.” It is not a perfect comparison, but it is useful because enterprises already understand why identity matters for humans and applications. AI agents extend that problem into a new class of non-human actors that can act for users, call tools, touch data and trigger workflows.
That is why agent identity, agent permissions, agent credentials, agent audit trails and runtime AI governance are becoming core infrastructure questions.
The Executive Takeaway
The next phase of enterprise AI will not be won by the companies that simply deploy the most agents. It will be won by the companies that can deploy agents with confidence.
That confidence will come from visibility, permissioning, credential control, runtime governance, auditability and clear ownership.
Executives should not wait for the first agent incident to ask these questions. They should ask them now:
- Do we know every agent running in the company?
- Does every agent have a clear owner?
- Does every agent have its own identity?
- Are permissions enforced at runtime?
- Are credentials held outside the agent?
- Can we revoke access for one agent?
- Can we audit every action?
- Do high-risk actions require human approval?
- Can we explain agent behavior to a regulator, customer or board?
AI agents are powerful because they can act. That is also why they must be governed.
The enterprise AI conversation is moving beyond model capability. It is moving toward trust, control and accountability. That is a healthy shift. It is also the shift that will determine which companies can scale agentic AI safely.
Related Video Briefings
This post builds on a series of short video briefings on AI agent governance, identity, permissions, credentials, runtime control and enterprise risk:
- Why can’t companies see what their AI agents are doing?
- Why isn’t OAuth enough to secure AI agents?
- How should companies manage credentials and tokens for AI agents?
- How do you move AI governance from policy to runtime?
- What does an uncontrolled AI agent actually cost a company?
- Why do AI agents hallucinate, and how do you catch it?
- How do you pass context between AI agents safely?
- Should AI agents be centralized or decentralized?
- How do you keep AI agents fast and affordable at scale?
- Do AI agents need a personality, and what are the risks?
- How do you stop AI agents from corrupting their own memory?
The broader lesson across the series is simple: agentic AI will not scale on intelligence alone. It will scale when enterprises can see what agents are doing, limit what they are allowed to do, understand why they acted and prove what happened afterward.
The companies that scale agentic AI safely will not be the ones that treat agents as clever chatbots. They will be the ones that treat agents as accountable actors inside the enterprise, with identity, permissions, credentials, visibility and governance built into the way they operate.
