Your enterprise runs a rigorous onboarding process for every new employee, which includes a background check, a signed contract, a defined access and authorization scope, and a named manager accountable for their actions. Your AI agents receive none of that. They are provisioned with cloud credentials, API keys, and permissions wide enough to operate, and they begin immediately. Ask your information security team for a current count of active agents. In most organizations, that question does not have a confident answer. That is not a technology shortfall. That is a governance failure.
By the end of 2026, Gartner projects that 40% of enterprise applications will embed task-specific AI agents. Fewer than 21% of enterprises have mature governance frameworks in place to manage them, according to Deloitte’s 2026 State of AI in the Enterprise report. The distance between those two numbers is where material risk currently lives.
AI agents aren’t just another application. They are autonomous identities that authenticate, access systems, make decisions, and execute tasks on behalf of the business. Yet most organizations govern them as if they were traditional service accounts.
The new identity problem nobody mapped
Non-human identities (NHIs), including service accounts, API tokens, automated pipelines, and AI agents, have always existed within enterprise environments. What has changed is the level of autonomous authority they now exercise and the complexity of the actions they perform independently.
A service account in 2018 authenticated to a single system and ran a scheduled task. An AI agent in 2026 reads customer data, generates a response, calls an external API, delegates a subtask to a second agent, completes a transaction, and records the outcome with no human reviewing any individual step. That agent sits in your IAM system beside hundreds of other service accounts, identically classified, and entirely invisible as a distinct risk category.
Discovering untracked AI agents is not unlike finding that half your building’s access cards were issued to individuals who never appeared in HR records. You cannot audit what was never registered. Most organizations that run a first NHI discovery exercise do not find a manageable handful. They find hundreds, distributed across:
- Cloud tenants and multi-account environments
- SaaS platforms adopted without central IT oversight
- Development and staging environments never decommissioned
- Third-party integrations that fell outside every prior access review cycle
What AI agents do and why traditional IAM cannot see it
Modern agents do not execute fixed, predictable tasks. They interpret instructions, reason across multiple steps, invoke different tools based on prior outputs, and spawn sub-agents, each operating under its own credentials. Within that delegation chain, consequential actions occur that no individual explicitly authorized; not through malicious intent, but because governance was never part of the deployment decision.
OWASP’s 2026 guidance identifies three primary threat vectors for autonomous systems:
- Goal hijacking: An agent’s objective is manipulated mid-execution to serve unintended purposes
- Tool misuse: Agents invoking tools beyond their intended operational scope
- Identity and privilege abuse: Agents accumulating permissions beyond what their role requires
Critically, these are not exclusively attacker-introduced conditions. They emerge from how agents are deployed and chained together in normal business operations.
Privilege drift develops when an agent provisioned with read access is later granted write permissions for a new requirement. The requirement eventually ends and however the elevated access does not. Because the agent is classified as a service account, it never surfaces in a quarterly access review.
Shadow agents are deployed directly by development teams or business units without the information security team’s involvement, operating for months on credentials assigned at inception.
Broken delegation chains are the hardest to resolve. When a parent agent authorizes a child agent that authorizes another, the original human authority becomes untraceable. After an incident, reconstructing accountability across a multi-vendor, multi-cloud chain is frequently not achievable with existing tooling.
The MCP attack surface: What GRC leaders need to know
The Model Context Protocol (MCP) defines how AI agents communicate with external tools and data sources including CRM systems, internal databases, financial APIs, and ticketing platforms. Widely adopted for its integration simplicity, it creates an access channel that most enterprise architectures have not formally mapped. Agents communicating via MCP are invisible to SIEM configurations not updated to capture that activity.
NIST’s AI Agent Standards Initiative, launched in February 2026, specifically identifies protocol-level agent access as a core governance requirement. If your organization has deployed any major AI platform in the past 18 months, MCP connections are almost certainly active. The question worth asking is whether any appear in your risk register; and if not, what that absence represents.
Five questions every CISO should ask about AI agents
These are not hypothetical scenarios. They are questions worth putting directly to your IAM lead and GRC function this week.
- If a senior auditor walked in tomorrow and asked for a complete list of every AI agent, API token, and automated pipeline currently active in your environment, how long would it take you to produce it, and how confident would you be that it is accurate?
Most organizations cannot answer this with confidence. That gap is where the governance program begins, not with policy, but with visibility into what is actually running. - Do your IAM policies formally distinguish between human users, service accounts, and AI agents?
Most do not. Agents inherit control frameworks built for processes that do not reason, delegate, or make contextual decisions. - When an AI agent built for a project that has since closed is still running today, with the original team gone and no one actively monitoring it, what governance process caught that and who owns the deprovisioning?
Orphaned agent credentials are among the most exploited privilege escalation vectors in cloud environments. The absence of a clear answer is itself an active risk, not a future one. - If one of your AI agents behaved unexpectedly today and accessed data outside its intended scope, would your security team know within the hour, or would it surface weeks later in an audit finding?
Most enterprises have no behavior baseline defined for their agents, which means anomalous activity goes undetected until it becomes a reportable incident. Detection capability is a governance requirement, not an optional enhancement. - When a multi-agent workflow produces an unexpected outcome, who holds documented accountability?
This question consistently produces silence in governance reviews. That silence is itself a finding.
How to govern AI agents in practice
Inventory must be a continuous operational function, not a project milestone. Platforms such as Microsoft Entra Workload Identities, CyberArk Conjur, and HashiCorp Vault provide the technical foundation; but governance value requires event-driven, automated updates. A discovery exercise completed last quarter is already outdated.
Agent credentials must be scoped and time-bound from provisioning. Every agent should operate under least-privilege, time-limited tokens tied to the business process it supports. An agent provisioned for a 90-day program should not retain active credentials in month fourteen.
Behavior baselines are as important as access controls. NIST is explicit on that front, i.e., governance without observability is unenforceable. For each agent in production, define, and monitor:
- Expected authentication frequency and typical tool invocation patterns
- Standard data access volume, scope, and authorized integration endpoints
Meaningful deviation from any of these signals compromise, undeclared scope expansion, or configuration drift. All three warrant investigation.
Formal accountability must be assigned to every production agent. A named individual must hold documented responsibility for each agentic workflow, recorded in the risk register. When an agent causes harm, the first regulatory question will be, “who owned this?”. Frameworks that cannot answer precisely are not frameworks in any operational sense.
AI agent governance is becoming a regulatory requirement
The compliance obligation exists today across multiple active frameworks:
- UAE National Strategy for AI 2031: One of the eight key objectives of this national strategy is to ensure strong governance and effective regulation, requiring organizations to embed clear accountability, oversight, and control frameworks for AI systems, including autonomous agents.
- UAE National AI Security Policy: This national policy was established to enhance cyber security in AI, aligned with the UAE’s national priority to be a global leader in cyber security; and enhance the security posture of organizations and individuals within the UAE using AI.
- NIST AI Agent Standards Initiative (February 2026): Defines identity governance, protocol-level access control, and continuous observability as core requirements for managing AI agents, reinforcing the need for organizations to implement auditable controls over agent behavior, access, and external integrations.
- OWASP Top 10 for AI Agents: Provides a risk-centric framework highlighting common vulnerabilities in AI agents such as goal manipulation, tool misuse, and identity/privilege abuse; serving as a baseline for securing agentic systems and guiding enterprise risk assessments and red teaming.
- EU AI Act, Article 14: Establishes mandatory human oversight requirements for high-risk AI systems, requiring organizations to ensure that AI, including autonomous agents, operates under appropriate supervision, with mechanisms to detect, intervene, and prevent unintended or harmful outcomes.
Regulators are not waiting for the market to self-correct. Organizations that respond to audits with documented, operational programs rather than policy statements are the ones that treated this as an active priority before the audit arrived.
Building AI agent governance: The practical starting point
For most organizations, closing this gap does not require a multi-year transformation. It requires a structured 60-to-90-day discovery and classification program that produces a defensible NHI inventory, identifies the highest-risk agents by access level and process criticality, and establishes governance architecture around those assets first.
The sequence matters, i.e., visibility before control and accountability before automation. Organizations that invest in automation before that foundation are in place typically find that they have systematized the problem rather than resolved it.
This program requires IAM architecture expertise, GRC framework knowledge, and direct experience with how AI agents are deployed at enterprise scale; a combination that rarely exists in full within a single internal team.
CPX’s Safe AI and GRC services work with security and compliance leaders across the UAE and the wider region to build exactly this program, from initial NHI discovery and agent access governance through to continuous compliance observability for AI-driven environments. The organizations that establish this program now will enter the next regulatory cycle with confidence. The ones that do not will spend it in remediation.
