AI agent security shifts from model risk to harness control

At a glance

What this is: This is a guide to AI agent security that shows why the real risk sits in orchestrators, tools, permissions, and workflows rather than the model alone.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern what AI systems can reach, what they can do, and how those actions are observed across the full identity estate.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read Nightfall's guide to AI agent security, MCP, and prompt injection

Context

AI agent security is the discipline of controlling what an agent can access, what it can influence, and what it can do once it is connected to enterprise systems. The article frames the problem around the harness around the model, which is where permissions, tools, data sources, and workflows turn an LLM into an operational identity.

That shift matters for NHI and IAM programmes because the control question is no longer only who authenticated, but which agent runtime, MCP server, or tool chain is acting with authority. The governance gap is visibility across the full agent lifecycle, especially when actions move faster than existing review or approval processes.

The topic is already visible in the wider market through tools such as Claude Code, Cursor, and other agentic runtimes. That makes this a mainstream identity-governance problem, not a niche AI security topic.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents complicate least-privilege design?

A: AI agents complicate least-privilege design because their tool use can change dynamically while the underlying permissions remain persistent. The system may need broad enough access to complete a task, but that same access can overshoot if scope is not tightly controlled. The fix is task-scoped authorisation with clear boundaries, not wider standing access.

Q: What do security teams get wrong about AI access risk?

A: Many teams focus on the model while ignoring the identity path that reaches it. If a service account or token can invoke AI infrastructure, then that credential becomes the real control point. The mistake is treating AI risk as a model problem instead of an access governance problem.

Q: How do organizations prove AI agent controls are actually working?

A: Organizations prove control effectiveness by showing which agents accessed which data, what actions they executed, and whether those actions stayed within approved task boundaries. Useful evidence includes logs, policy decisions, anomaly alerts, and review records. Without that chain, governance is mostly declarative.

Technical breakdown

Orchestrator and agent infrastructure: where agent identity risk actually lives

The orchestrator is the runtime that sequences agent activity, selects when tools are called, and pushes the agent toward a goal. Agent infrastructure is the surrounding layer of tools, APIs, MCP servers, permissions, memory, and data sources that determines what the agent can touch. Together they create the effective identity boundary for the system. In practice, the model may be unchanged while the orchestration layer expands privilege, data reach, and action scope. That is why many failures show up as access abuse, not model compromise. The security question becomes whether the runtime can constrain action paths, not whether the model can answer safely.

Practical implication: Map every agent to its orchestrator, tool set, and permission envelope before you allow production access.

MCP, tool requests, and indirect prompt injection

MCP gives agents a standard way to communicate with enterprise systems, which is useful but also expands the number of reachable resources. Tool requests are where the agent attempts action, while tool responses are where external content can inject instructions back into the workflow. Indirect prompt injection exploits that response path by hiding malicious instructions in documents, websites, or records that the agent consumes. This is why response filtering, tool boundary checks, and content provenance matter together. The problem is not just bad prompts. It is untrusted content influencing an identity that can still act.

Practical implication: Treat every external tool response as potentially adversarial input before the agent can execute the next step.

Agent observability and telemetry for AI security

Agent observability is the ability to see which agents are active, which tools they call, what data they access, and what actions they take. Telemetry such as prompts, tool requests, tool responses, execution events, and MCP interactions provides the evidence trail security teams need for investigation and control tuning. Without telemetry, organisations cannot answer basic questions about shadow AI, policy violations, or scope drift. The article makes the point plainly: you cannot secure what you cannot see. For identity teams, that means control design has to be paired with auditability from the start.

Practical implication: Instrument agent activity with telemetry before broad rollout, then use the logs to enforce least privilege and investigate misuse.

Threat narrative

Attacker objective: The attacker wants to hijack agent behaviour so the connected system leaks data, exposes credentials, or performs harmful actions at enterprise scale.

1. Entry occurs when a user or application connects an agent to enterprise tools, data sources, or MCP servers with more access than the task truly needs.
2. Escalation happens when tool requests, poisoned skills, or indirect prompt injection steer the agent into broader data access, unauthorized systems, or unintended actions.
3. Impact follows when the agent exfiltrates sensitive data, reveals credentials, or performs workflow actions that expand the blast radius beyond the original request.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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

NHI Mgmt Group analysis

AI agent security is really identity security with a new execution layer. The article is clear that the decisive control surface is the harness around the model, not the model alone. Once an agent can query data, call tools, and execute workflows, IAM and NHI controls become the only durable boundary. Practitioners should read this as a governance shift, not a tooling novelty.

Agent infrastructure is becoming the new identity perimeter. Permissions, MCP servers, data sources, memory, and workflow hooks now determine the practical blast radius of an agent. That means the classic idea of a static account with a fixed purpose is no longer enough to describe risk. Teams need a named concept for this problem, and the right one is agent harness exposure: the degree to which orchestration and surrounding controls determine what an agent can do.

Shadow AI is evolving into shadow execution. The article’s AI Activity Discovery section shows that organisations often discover agents only after they are already connected to tools and data. That is a governance failure because discovery lag creates unreviewed access paths. The implication for practitioners is that lifecycle control has to start at discovery and continue through runtime monitoring.

Indirect prompt injection is a content governance problem as much as an AI problem. Tool responses can carry instructions back into the agent, which means untrusted content can influence decisions after the initial prompt has been approved. This is why content provenance, tool response inspection, and policy enforcement at workflow hooks belong in the same control conversation. Security teams should treat response paths as identity-adjacent attack surfaces, not just data pipes.

MCP adoption is multiplying identity decisions faster than most programmes can govern them. Each connected server adds another access path, another trust relationship, and another audit requirement. That expansion does not automatically mean the agent is autonomous, but it does mean the identity surface is widening in ways traditional access review cycles struggle to keep up with. Practitioners should re-evaluate every new MCP integration as a governed access decision, not just a connectivity choice.

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 the AI Agents: The New Attack Surface report.
• Another finding from the same report shows that 80% of organisations say their AI agents have already performed actions beyond their intended scope, including access to unauthorised systems and exposed credentials.
• For a broader control lens, the OWASP Agentic Applications Top 10 helps teams map those failures to specific agentic risk categories.

What this signals

With only 52% of companies able to track and audit the data their AI agents access, the first maturity step is not policy tuning but basic observability. That gap becomes more serious as teams connect agents to more tools, more memory, and more enterprise data.

Agent harness exposure: the practical risk is no longer just whether an AI model is safe, but whether the surrounding runtime can be governed as an identity boundary. As agent adoption grows, this becomes a combined NHI, IAM, and data-governance problem rather than a point AI control.

Teams should align their agent governance work with the OWASP Agentic AI Top 10 and their internal discovery process so that new integrations are reviewed before they become invisible production dependencies.

For practitioners

• Inventory agent runtimes and orchestrators Build a register of every agent runtime, the tools it can call, the data sources it can reach, and the workflow owners responsible for that access. Use that inventory as the starting point for NHI and IAM review.
• Gate MCP server onboarding through access review Treat each new MCP server like a privileged integration and require a documented business purpose, approved scope, and review date before it is connected to an agent.
• Instrument tool requests and responses Capture prompts, tool calls, tool responses, and execution events so security teams can investigate abuse, trace data movement, and reconstruct scope drift after the fact.
• Apply least privilege to agent workflows Reduce the systems, records, and actions available to each agent runtime, then revalidate the scope whenever the workflow or data source changes.
• Separate discovery from production access Do not allow undiscovered or unclassified AI activity to connect to enterprise systems. Require discovery first, then controlled onboarding with logging and ownership.

Key takeaways

• AI agent security is an identity problem because the real control surface sits in orchestrators, tools, permissions, and workflows.
• Visibility is still the weakest control, with only 52% of organisations able to track and audit the data their AI agents access.
• Practitioners should govern agent runtimes as connected identities, with discovery, least privilege, and telemetry in place before production rollout.

Key terms

• Agent Orchestrator: A system that coordinates multiple AI agents, directing tool use, API calls, and task hand-offs. The orchestrator controls the credentials of every agent it directs — making it a high-value attack target.
• Agent Infrastructure as Code: Agent Infrastructure as Code is the practice of defining AI agent permissions, tool access, execution settings, and containment rules in version-controlled files. It applies the infrastructure-as-code model to autonomous systems, making security boundaries reviewable before deployment and auditable after change.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Agent telemetry: Operational data describing what an AI agent did, which tools it called, how much it consumed, and what resources it touched. Telemetry is essential for audit, incident response, and behavioural governance because agent decisions are otherwise difficult to reconstruct.

What's in the full article

Nightfall's full blog post covers the operational detail this post intentionally leaves for the source:

• How the agent orchestrator, harness, and workflow hooks fit together in practice
• Examples of prompt injection, tool misuse, and indirect prompt injection across agent responses
• Why MCP expands access paths and how that changes tool governance
• Nightfall's explanation of telemetry and visibility patterns for agent security teams

👉 Nightfall's full post covers the harness model, agent workflows, and the security terms practitioners need to track.

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.