AI vulnerability discovery is no longer the hard problem

At a glance

What this is: The article argues that AI vulnerability discovery is becoming less of a constraint, while execution speed, semantic attack surface, and agent harness governance now define the real security problem.

Why it matters: That matters to IAM practitioners because AI agents and related tooling introduce new identity, privilege, and oversight questions that traditional access controls were not designed to answer at production speed.

👉 Read terra’s analysis of AI vulnerability discovery and execution risk

Context

AI security programmes are moving from discovery-heavy conversations to execution-heavy ones. Once adversaries can test, iterate, and chain conditions faster than human review cycles, the question is no longer whether a weakness exists but whether it can be reached, amplified, or operationalised in production. That shift is especially relevant for AI agent security, where the harness, prompts, retrieval paths, and tool permissions become part of the security boundary.

For identity teams, the key issue is that AI systems increasingly behave like privileged software entities with context-driven access. That brings agent governance, workload identity, and secret handling into the same operational frame. The article’s starting point is not unusual for the current market, but its emphasis on execution over discovery is the more durable signal for security and IAM programmes.

Key questions

Q: How should security teams govern AI models that can call tools and access data?

A: Security teams should govern AI models as non-human identities with named owners, limited scope, short-lived credentials, and continuous authorization. The critical shift is to treat every tool call, data read, and update path as a privileged action that can be logged, revalidated, and revoked. Without that discipline, model risk becomes identity risk.

Q: Why do agent frameworks create new access-risk problems for IAM teams?

A: Because they let runtime decisions, tool calls, and stateful workflows happen inside familiar development stacks, which can hide where authorisation actually occurs. When identity is embedded in code and orchestration, access can expand faster than governance can explain or certify it.

Q: What breaks when harness controls are treated like ordinary configuration?

A: The system can drift into implicit trust. If prompts, retrieval paths, and escalation rules are modified without security review, the agent may gain broader interpretation or action rights than intended. That creates a hidden privilege expansion path, especially when the agent operates over sensitive repositories or production tools.

Q: Who is accountable when a third-party AI agent misbehaves in production?

A: The organisation using the agent remains accountable for the outcomes, even if a vendor supplies the platform. Security, legal, compliance, and business owners should share responsibility for controls, monitoring, and incident response. If the agent can affect customers or regulated data, accountability cannot be outsourced with the technology.

Technical breakdown

Why execution speed matters more than vulnerability discovery

Modern AI-assisted attack workflows compress the time between finding a weakness and testing it at scale. Discovery tools can surface more issues, but they do not reduce the attacker’s ability to iterate through conditions, alternate inputs, and environmental assumptions. In practice, this means vulnerability management becomes a question of exploitability and reachability, not raw count. For AI systems, that matters because small logic or access-control flaws can be probed in many more ways than a static application ever faced.

Practical implication: prioritise exploitability scoring and containment paths over simple vulnerability volume.

What the agent harness actually controls

The harness is the operational boundary around an AI agent. It includes prompts, tool definitions, retrieval pipelines, escalation logic, and the rules that translate intent into action. If the harness is loosely managed, the agent can interpret context in ways that expand access beyond what operators intended. This is where AI governance intersects with identity: tool permissions, delegated access, and runtime authorisation all need explicit boundaries, not implied trust.

Practical implication: treat harness configuration as security-controlled policy, not as adjustable application settings.

Why semantic attack surface changes control design

In agentic systems, anything the agent can read may influence what it does. Repository structure, comments, naming conventions, and surrounding content can all become inputs to decision-making. That creates a semantic attack surface, where the problem is not code corruption but contextual manipulation. Traditional controls that focus on binaries, signatures, or static scanning do not fully address this class of risk, because the vulnerable object is the reasoning path itself.

Practical implication: review readable content, retrieval sources, and tool outputs as governed inputs, not passive metadata.

Threat narrative

Attacker objective: The attacker aims to influence agent behaviour so the system acts beyond its intended scope and reveals or manipulates sensitive resources.

1. Entry occurs when an attacker places or exposes content that an AI agent can read inside the agent’s working context.
2. Escalation happens when the harness or retrieval layer allows that content to shape tool use, scope interpretation, or access decisions.
3. Impact follows when the agent performs actions outside intended boundaries, exposing data, changing state, or widening the attack path.

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

Execution, not discovery, is now the limiting factor in AI security. AI programmes can surface more findings than teams can meaningfully process, but that does not reduce attacker capability. Once attackers can iterate faster than governance can respond, the real question becomes whether a weakness can be reached and weaponised. The practical conclusion for security leaders is that prioritisation and containment now matter more than counts.

The harness is becoming the identity boundary for AI agents. When prompts, tools, retrieval, and escalation rules define what an agent may do, the security problem moves into runtime authorisation. That means agent governance, workload identity, and secret handling cannot be separated. Organisations that treat harness settings as ordinary configuration are creating an access-control gap they will not detect early enough.

Semantic attack surface is a distinct control failure mode. This article usefully sharpens a concept many programmes still overlook: content that an agent can read becomes part of the attack surface. That is a governance assumption failure, not a tooling gap. The practical conclusion is that readable context must be classified, scoped, and monitored with the same discipline as executable code.

Validated exposure is a better security unit than theoretical vulnerability. The article correctly distinguishes between weaknesses that exist in principle and those that are reachable in a given environment. That distinction should reshape how AI vulnerability operations are organised, because security teams need to decide what is exploitable, not merely what is present. The practical conclusion is to manage remediation around exposure paths.

AI security programmes are converging with NHI governance. Once agents can call tools, access data, and act at runtime, they behave like non-human identities with policy, privilege, and accountability implications. That creates a direct bridge to NHI controls, especially around credential scope, delegated access, and reviewability. The practical conclusion is that AI governance and NHI governance now need shared operating assumptions.

From our research:

• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to 2024 Non-Human Identity Security Report.
• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts.
• Forward pivot: The Top 10 NHI Issues help teams map those maturity gaps to concrete governance priorities.

What this signals

The likely programme shift is from discovery-centric AI security to control-centric AI operations. Teams should expect more scrutiny on harness governance, privileged tool use, and whether runtime decisions are auditable in the same way as human-admin actions. That is where NHI governance and AI governance start to overlap in practical terms.

Semantic exposure management: content that an agent can read must be governed as a live input channel, not as inert background data. That has implications for repository hygiene, retrieval policy, and the classification of documents that can influence privileged actions. The most useful next step is to align those controls with established identity and access principles.

The reporting burden will also move upward. Leaders will need to explain not just how many findings exist, but which exposures are reachable, which tool permissions are justified, and who owns runtime actions taken by agents. That is a change in governance posture, not just a change in tooling.

For practitioners

• Define the harness as a governed control layer Document prompts, retrieval sources, tool definitions, and escalation rules as security-relevant assets. Put change control around any update that expands context, tool reach, or action scope, and review harness changes the same way you review privileged access changes.
• Prioritise exploitable exposure over raw finding counts Separate theoretical weaknesses from issues that can actually be reached in the current environment. Feed that distinction into triage, remediation SLAs, and reporting so teams focus on attack paths that can lead to sensitive data or production state changes.
• Apply NHI controls to agent tool access Treat AI agents as non-human identities when they use APIs, data stores, and administrative tools. Scope credentials tightly, remove standing privilege, and align tool access with the minimum runtime permissions needed for the session.
• Review readable context as part of the attack surface Inventory the documents, repositories, comments, and retrieval feeds an agent can consume. Classify them by sensitivity and constrain what the model may interpret from high-risk sources, especially where content could influence privileged actions.

Key takeaways

• AI security is moving from finding weaknesses to controlling execution, and that changes how risk should be prioritised.
• Agent harnesses function as security boundaries, which makes runtime authorisation and delegated access core governance issues.
• NHI principles now apply to AI agents because tool use, scope, and accountability are identity problems as much as they are AI problems.

Key terms

• Agent Harness: The agent harness is the runtime layer that wraps a model and turns it into an acting system. It usually includes the loop, tools, context handling, permissions, hooks, and logs. In security terms, it is often the real place where privilege sits and where identity evidence must be governed.
• Semantic Attack Surface: Semantic attack surface is the set of readable inputs that can influence how an AI system behaves, even when those inputs are not executable code. In agentic systems, documentation, repository structure, comments, and retrieved context can all become security-relevant because they affect decisions.
• Exposure Validation: The process of confirming what data actually left the environment, where it came from, and how it could be abused. It is a post-incident governance step that links incident response, data classification, and identity risk assessment.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

What's in the full article

terra's full article covers the operational detail this post intentionally leaves for the source:

• The specific argument Terra makes about the CSA Mythos brief and where it agrees or diverges from the draft priorities.
• The Claude Code vulnerability example and the mechanics of the symbolic-link handling flaw described in the article.
• The article's full view of the harness as a control layer, including why Terra treats it as the primary boundary for agent behaviour.
• The prioritisation model Terra recommends for separating theoretical vulnerability from validated exposure in an AI security programme.

👉 terra’s full article covers the harness boundary, validated exposure, and AI agent accountability in more detail

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and workload identity. It is designed for practitioners building control models across identity, AI, and access programmes.