For CISOs navigating the most operationally acute security problem in enterprise AI: agent identity, access governance, and what happens when you cannot answer the basic questions about what your agents are doing.
The security conversation about AI has spent most of the last two years focused on the wrong things.
Prompt injection. Hallucination. Model bias.
These are real concerns, and they deserve attention. But the problem that is actually keeping CISOs up right now - the one that 62% of surveyed security leaders named as the biggest AI security problem on their desk - is more fundamental and more operationally immediate.
It is the identity and authorisation gap.
An AI agent is not a chatbot. It is a system that receives instructions, accesses enterprise data, invokes APIs, and takes actions across multiple applications - at machine speed, autonomously, and often without a human in the loop for each individual step. It has an identity. It has credentials. It has permissions granted to it at some point by someone. And in 92% of large enterprises surveyed in 2026, the CISO cannot fully account for those identities, those credentials, or who granted those permissions.
That is not a risk on the horizon. That is a risk in production right now.
The four questions that expose the gap
The identity and authorisation gap in enterprise AI is most clearly visible when you try to answer four questions that, for any human employee or traditional software system, you should be able to answer immediately.
Which agent owns which credential? In most enterprise deployments, AI agents are provisioned with credentials - API keys, service account tokens, OAuth grants - that give them access to enterprise systems. Who issued those credentials? Are they individual to the agent or shared across multiple agents or with human users? When were they last rotated?
Who authorised its permissions? An agent that can read HR data, query a CRM, and write to a database has three separate permission grants. Each of those grants was authorised by someone - or nobody, if the agent inherited permissions from a service account that was already broadly scoped. Can you produce the authorisation record for each permission?
What happens when its task changes? An agent deployed to answer HR queries is later repurposed to help with financial reporting. Its permissions were set for the first task. They were not reviewed for the second. The agent now has access to financial data under permissions that were never explicitly granted for that purpose.
Can its access be revoked instantly? If a compromised agent is detected, how quickly can its access be terminated across every system it touches? If the answer involves manual steps across multiple platforms - revoking an API key here, deactivating a service account there, removing an OAuth grant somewhere else - the containment window is measured in hours, not seconds.
If you cannot answer all four cleanly, you have a gap. And 95% of CISOs surveyed in 2026 said they doubt they could detect or contain a compromised agent at all.
“AI agents are now acting across SaaS, cloud, and endpoint environments with identities and permissions that traditional IAM controls were not designed to govern. The security model built for human users does not map cleanly to autonomous systems that never stop, never sleep, and never ask for permission to continue.”
Why traditional IAM doesn’t cover this
Most enterprise identity and access management infrastructure was designed for human users and static software systems. It handles authentication well. It handles role-based access control well. It handles periodic access reviews reasonably well.
What it was not designed for is the access pattern of an AI agent - which may call dozens of different APIs in the course of a single task, may have dynamic permission needs that change with the task it is performing, and may operate continuously across multiple sessions without the natural pause points that human-centric IAM processes rely on.
The specific gaps that enterprise IAM leaves in AI agent governance are:
No concept of task-scoped permissions - access grants in traditional IAM are role-based, not task-specific. An agent assigned the “HR reader” role gets all HR data access, not just the specific fields its current task requires.
No real-time permission adjustment - traditional IAM permissions are set and periodically reviewed. They are not dynamically adjusted based on what the agent is doing in a given session.
No agent-level audit trail - most IAM systems log human user actions. Agent actions - API calls made, data accessed, decisions triggered - are often not captured in a format that makes the agent’s behaviour reconstructible after the fact.
No automated containment - revoking a compromised agent’s access requires manual intervention across every system the agent has credentials for. There is no equivalent of disabling a human employee’s badge that works simultaneously across all enterprise systems.
What agent identity governance requires
The practical approach to agent identity governance that security leaders are converging on involves four structural requirements - each of which addresses one of the gaps traditional IAM leaves.
Agent inventory. Before you can govern agent identities, you need to know what agents exist. A comprehensive, continuously maintained inventory of every AI agent deployed in the enterprise - what it does, what credentials it holds, what permissions it has, who deployed it, and when - is the foundation. Without it, every other governance control is operating blind.
Least-privilege, task-scoped access. Agents should be provisioned with the minimum access required for their specific task - not the minimum access required for their role category. An agent performing employment verification should have read access to employment status and salary fields. It should not have access to the full HRIS data model simply because it is in the “HR tools” access tier.
Continuous behaviour monitoring. Agent governance cannot rely on periodic access reviews. It requires real-time monitoring of agent behaviour - detecting when an agent accesses data outside its typical pattern, when it makes API calls that fall outside its defined task scope, or when its output behaviour changes in ways that suggest compromise or misconfiguration.
Instant revocation capability. When a compromised agent is detected, access termination needs to happen at the infrastructure level, not through manual steps across individual systems. The unified API layer that governs what data the agent can access is the natural control point - revoking the agent’s API credentials at the unified layer severs its access to all downstream systems simultaneously.
The data access layer is the control point
For AI agents operating in financial services, HR, and enterprise operations - where the data being accessed is sensitive, regulated, and consequential - the unified API layer that sits between the agent and the enterprise data systems is the most important control point available to the CISO.
An agent that accesses employment data, payroll records, or customer financial data through a governed, audited API layer leaves a complete trace of every data access event. Permissions are granted at the API layer and enforced consistently regardless of which downstream system the data originates from. Revocation at the API layer is instant and complete. The audit trail is a byproduct of the architecture, not a separate logging project.
This is the control posture that Tartan’s HyperSync enables for AI agents operating in BFSI and enterprise environments - a unified API layer with granular, task-scoped access controls, immutable audit logging, and instant revocation capability. The agent calls one endpoint. The governance happens at that endpoint. The CISO can answer all four questions.
The AI agent identity problem is not going to be solved by the model vendors. It is going to be solved by the infrastructure layer that governs what agents can access, logs what they do, and can terminate their access when something goes wrong. That infrastructure needs to be in place before the agents go into production - not built in response to an incident that has already happened.
