AI agents for cybersecurity expose gaps in runtime governance

At a glance

What this is: This analysis shows that AI agents for cybersecurity are already delivering operational value, but their machine-speed actions, privileged access, and MCP-connected tool use expose governance gaps that traditional browser-era controls miss.

Why it matters: It matters because IAM, PAM, and identity governance teams now have to control agent identities, runtime permissions, and approval paths across security operations, not just human users and static service accounts.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
• The ratio reaches 144 to 1 in cloud-native environments.

👉 Read WitnessAI's analysis of AI agents for cybersecurity and runtime controls

Context

AI agents for cybersecurity are software systems that plan, choose tools, and take action in security workflows rather than merely drafting a recommendation. The governance problem is not their usefulness, but the fact that they now operate with privileged access in terminals, IDEs, and CI/CD pipelines that older monitoring assumptions do not cover.

That creates a direct identity security challenge for IAM, PAM, and NHI governance programmes. The article's core claim is that value comes from supervised autonomy, while risk comes from prompt injection, over-permissioned machine identities, and shadow agents that sit outside the asset inventory your controls depend on.

Key questions

Q: How should security teams govern AI agents that can take runtime response actions?

A: Treat them as privileged NHI workloads with explicit scope, short-lived authority, and full action logging. Separate read-only investigation from enforcement, require approval for high-impact containment, and review the agent’s effective permissions on a schedule. If the agent can change runtime policy, it needs the same governance discipline as any other elevated identity.

Q: Why do AI agents create more risk than traditional automation?

A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.

Q: What are the signs that AI governance is failing in the enterprise?

A: Common warning signs include rapid growth in AI use without matching policy coverage, sensitive files being copied into personal accounts, and a large share of AI apps carrying high or critical risk. Another indicator is weak visibility into who is using which tools and what data they are sending. If teams cannot answer those questions, governance is not working as intended.

Q: When should organisations require human approval for an AI agent action?

A: Require human approval when the action could change infrastructure, expose sensitive data, move laterally across systems, or trigger a business-critical workflow that is hard to reverse. Approval is also warranted when the agent’s decision depends on ambiguous input or external data that cannot be trusted at face value. High-consequence actions need a human stop point.

Technical breakdown

How supervised autonomy differs from scripted automation

Supervised autonomy means the agent can decide which investigative steps to take, but a human still approves irreversible actions. That differs from SOAR playbooks, which follow predefined if-then logic, and from copilots, which wait for a human to act. The practical issue is that the governance target is not the output alone, but the runtime sequence of tool calls, prompts, and decisions. Once agents can choose actions dynamically, the control point shifts from ticket approval to execution-time enforcement.

Practical implication: treat agent approval as a runtime control, not a workflow formality.

Why non-human identities become the control plane for agents

Most security agents execute through non-human identities, delegated permissions, service accounts, or other machine credentials. That matters because the agent's effective authority is defined by the identity it uses, not by the interface that launched it. If the identity is over-permissioned, the agent can move faster than human review cycles and amplify a single mistake into broad impact. This is an IAM and PAM problem first, and an AI problem second.

Practical implication: bind each agent to a unique identity with narrowly scoped privileges and clear sponsorship.

How MCP connections widen the attack surface

Model Context Protocol servers expose tools and data sources to agents, which makes them part of the trust boundary. In practice, that means an agent can be steered through retrieved content or tool responses into actions the operator did not intend. Browser proxies rarely see this traffic, because developers run agents in IDEs, terminals, and pipelines that bypass normal inspection points. The architectural lesson is that visibility must exist where tools are actually called, not only where users log in.

Practical implication: enforce allow-lists and inspection before tool execution, especially for MCP-connected systems.

Threat narrative

Attacker objective: The objective is to turn trusted security automation into an execution path for unauthorised access, data exposure, or operational disruption.

1. Entry begins when a legitimate security agent receives malicious instructions through retrieved content, tool output, or an exposed MCP-connected source.
2. Escalation occurs when the agent uses its permitted but over-broad machine identity to access systems, data, or actions beyond the operator's intent.
3. Impact follows when the redirected agent exfiltrates data, changes detections, or triggers unauthorised security operations at machine speed.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime policy, not static policy, is the governance boundary for AI agents: security teams are no longer dealing with tools that wait for approval at each step. When an agent can choose and sequence actions inside a security workflow, the decisive control is whether enforcement exists at the moment of execution. That shifts the governance question from documentation to runtime proof, which is where most identity programmes are still thin. Practitioners need to treat every action as a live authorisation event.

Least privilege stops being a provisioning-time exercise when agents can chain actions dynamically: least privilege was designed for actors whose intent is knowable before execution begins. That assumption breaks when a security agent decides which tool to use, which system to query, and when to stop. The implication is that identity governance must account for decision-time behaviour, not just assigned entitlements, because the permission envelope can expand through the agent's own runtime choices.

AI agent identity is now a first-class NHI governance problem: these agents do not sit outside IAM, they inherit it. Once an agent is given delegated access, the questions become ownership, sponsorship, revocation, and evidence of control across the full lifecycle. That is why the same discipline used for service accounts and workloads now has to extend to security agents, especially where action logging and approval boundaries determine accountability.

Shadow agents create an inventory failure before they create a technical failure: if the enterprise cannot identify an agent, it cannot govern its permissions, monitor its tool use, or prove compliance. The named concept here is runtime governance gap, which is the distance between policy intent and enforcement on live agent actions. The practitioner takeaway is simple: inventory is no longer a reporting task, it is a security prerequisite.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• From our research: The ratio reaches 144 to 1 in cloud-native environments, according to Ultimate Guide to NHIs , Key Challenges and Risks.
• From our research: Read our OWASP Agentic AI Top 10 guide for the control patterns most relevant to agent tool misuse and prompt injection.

What this signals

The governance baseline for AI agents will increasingly look like workload identity management with stronger runtime inspection. Organisations that still treat agent access as an extension of user automation will struggle to prove enforcement, especially once agents operate in IDEs and pipelines outside normal browser monitoring. The concept to watch is runtime governance gap: it describes the space between policy intent and the actual moment of execution, and it is where most agent control failures will surface.

With only 52% of companies able to track and audit the data their AI agents access, the operational question is no longer whether agents are useful but whether the identity layer can observe them consistently. That visibility gap will drive more board scrutiny on approval boundaries, human sponsorship, and evidence of control in AI workflows.

Practitioners should prepare for a split architecture: read-only autonomous work on one side, and high-risk actions routed through explicit controls on the other. That model aligns with NIST AI Risk Management Framework thinking and helps identity teams define where delegated access ends and human accountability begins.

For practitioners

• Assign unique identities to every security agent Use a dedicated non-human identity for each agent, with task-scoped permissions, named human sponsorship, and revocation tied to the workflow owner.
• Enforce tool allow-lists before execution Place approval and policy checks in the execution path so the agent cannot call unapproved tools, MCP servers, or data sources before the action runs.
• Classify irreversible actions for human approval Separate read-only work from any action that can change detections, access, or infrastructure, and require a human gate for the latter.
• Track agent activity as identity evidence Log who initiated the agent, which identity it used, which tools it touched, and what enforcement existed at the time of decision.
• Scan for unsanctioned agents and MCP servers Inventory developer and security tooling in IDEs, terminals, pipelines, and local frameworks to find shadow AI that bypasses browser-era monitoring.

Key takeaways

• AI agents for cybersecurity are becoming operationally valuable, but their runtime behaviour changes the identity problem from static access control to live enforcement.
• Privileged non-human identities, shadow agent deployments, and MCP-connected tools create a control gap that many existing monitoring stacks do not see.
• The practical answer is not blanket prohibition, but tighter runtime governance, scoped identities, and human approval for irreversible actions.

Key terms

• AI Agents: AI agents are autonomous software entities that act within organisational environments and make runtime decisions within assigned boundaries. They can hold identities, authenticate to systems, and exercise permissions, which makes them comparable to other non-human identities that require inventory, governance, and continuous activity monitoring.
• Runtime Governance: Runtime governance is the set of controls that verify what a system or agent is actually doing after deployment. It combines monitoring, authorization checks, and access validation so teams can detect drift, misuse, or excessive privilege in motion rather than assuming build-time policy still holds.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.

What's in the full article

WitnessAI's full analysis covers the operational detail this post intentionally leaves for the source:

• How its visibility layer identifies agents and MCP servers across IDEs, terminals, applications, and local frameworks.
• How its agentic control path allow-lists tools and blocks unauthorised tool calls before execution.
• How its prompt protection scans inbound instructions and outbound responses to reduce injection risk at runtime.
• How the article maps captured agent actions back to the initiating human identity for accountability.

👉 The full WitnessAI article covers agent visibility, tool control, and prompt protection in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.