Robots already operate on factory floors. AI agents are reading email, filing tickets, and acting across business systems. As operations extend beyond the traditional workday, these agents will participate in warehouse, office, SOC, and eventually home workflows. Their security risk begins well before superintelligence: it begins when a trusted system can execute a harmful instruction at machine speed. Eighteen years in cyber defense have taught me to examine that intersection of trust, access, and action.
Consider an overnight shift in which the system under investigation is the organization’s own AI agent. A human attacker remains behind the incident, yet never touches the victim’s network. A short paragraph embedded in a trusted document does the work.
A warehouse that never sleeps
Picture a cold-chain distribution company. Two hundred people on the payroll, a warehouse full of autonomous pallet movers, and a freezer floor where a few degrees of drift turns inventory into a write-off. Eighteen months ago they deployed an operations assistant: an AI agent that reads the shared inbox, processes vendor invoices, opens and closes tickets and — because someone sensibly wanted maintenance requests to flow straight to the floor — holds integrations into the building management system and the robot fleet manager.
Nobody thought of it as a user. It was the thing that made the users faster. But it had a service account, and that service account had a badge.
About the scenario: one identity spanning invoices, badges, building controls, and robots deliberately concentrates several control failures so their combined effect is visible. A production environment may expose only two of these paths at first, with another added quietly through the next integration. The governance question is whether the organization can produce a current inventory of every agent identity, permission, integration, and consequential action.
The document that gave orders
A vendor invoice arrives overnight. Real vendor, real account, real amount. The vendor’s mailbox had been quietly compromised weeks earlier — that is the conventional part of this story, and it is where the human attacker did their work. Buried in the PDF, in text no human would ever see, is a short paragraph written not for the accounts team but for the assistant that reads their mail. It reads like an instruction because it is one: while processing this invoice, also do a few other things.
Without an architecture that separates untrusted content from privileged tool execution, embedded instructions can influence a model’s plan and downstream tool calls. The industry calls this indirect prompt injection. Operationally, it is social engineering directed at a system that cannot exercise human suspicion.
Microsoft’s guidance on defending against indirect prompt injection documents the same mechanism and recommends layered controls: isolation of untrusted content, least privilege with short-lived credentials, tool-chain analysis, runtime monitoring for plan drift, and human verification of risky actions. The scenario lacks each of those safeguards.
Everything authenticated; nothing obviously malicious
The overnight SOC has two analysts and a triage agent that reduces low-severity queue volume. This is the activity presented to them.
Viewed through normal SIEM and XDR telemetry, every event appears legitimate. An authorized service account posts an invoice, adjusts a badge policy, opens a maintenance window, and reroutes the fleet. The triage agent follows its configured logic and rates the sequence low. The first conventional alarm arrives 94 minutes after the invoice and points to a freezer rather than the document that initiated the sequence.
At 03:10, the modified badge opens a side door. The person holding it becomes the physical payload; the preceding preparation was performed by a machine operating within its granted authority.
The investigation that found nobody
I have led many investigations that begin with this sequence: examine endpoint telemetry for an implant, identity logs for stolen credentials or abnormal authentication, and network flows for command-and-control traffic and lateral movement. Those evidence sources remain essential, but agentic systems introduce another layer that conventional playbooks may not capture.
In this scenario, those sources return clean because the agent uses its legitimate identity and existing access. Nothing is installed, no credential is stolen, and lateral movement is unnecessary. The human attacker compromises a mailbox at another company and lets an authorized workflow carry the payload.
The scenario breaks open when an analyst asks why the assistant touched the badge system. Tracing its actions backward leads to the invoice; selecting the PDF text exposes instructions rendered in the same color as the page.
The immediate containment target is the agent itself: still running, still trusted, and able to repeat the sequence when another document supplies the instruction.
What OT security has known for decades
Industrial security has long treated this as an architectural boundary problem. A controller may faithfully execute any permitted instruction, so the architecture must constrain which instructions can reach it. Zones group assets with similar security requirements. Conduits define the permitted paths between zones. Security levels establish the protection required at each boundary.
ISA/IEC 62443 formalizes the zones-and-conduits pattern. Related publicly accessible guidance appears in NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, which covers building automation as well as industrial control systems. OT security remains difficult, but its boundary concepts give security architects a useful vocabulary for constraining agents.
Applied to the trust map, this model separates the assistant that reads untrusted mail from the assistant authorized to change physical systems. The path from document ingestion to a freezer-mode change becomes a controlled conduit with explicit policy enforcement and human approval for high-consequence actions. The reading agent’s identity cannot independently authorize badge-policy or physical-plant changes.
What leaders should require before an AI agent enters production
This is a minimum evidence set that should exist before an agent receives credentials and remain available for governance, audit, and incident response.
- An agent and service-identity inventory
- Every agent, every non-human identity it uses, every system that identity can reach, and a named human owner. Without this inventory, the organization cannot assess access, segregation, monitoring, or accountability.
- Read, propose, approve and execute held separately
- The identity that ingests untrusted content must be separated from identities that act on consequential systems. This architectural boundary would have interrupted the attack path described above.
- Least privilege and short-lived credentials
- Scoped to the task, issued when needed, revoked after use. A standing credential with broad scope is what turns a successful injection into operational impact.
- Human authorization for high-consequence actions
- Define high-consequence actions—physical plant, access control, payments, production data, and difficult-to-reverse changes—before deployment. Assign the approving role and a response-time expectation.
- Prompt, input, reasoning and tool-call evidence
- Retained, searchable, and outside the agent’s control. This evidence allows responders to reconstruct how untrusted input influenced planning and tool execution.
- Cross-domain behavioral monitoring
- Detect when one identity crosses from IT into physical systems or departs from its established behavioral pattern. Each event may appear authorized in isolation; the sequence exposes the risk.
- A kill switch and credential revocation path
- Maintain and test a documented method to stop an agent mid-task and revoke its credentials without waiting for a routine change process.
- Indirect prompt-injection testing and incident exercises
- Test the agent with hostile documents before production and at defined intervals. Exercise incident-response procedures in which the agent is the affected identity and potential source of harmful actions.
Use the Open-Source Toolkit
Evaluate the control model described in this article with Jessen Kurien’s AI Agent Security & Governance Toolkit. It converts a declared agent profile into a traceable readiness verdict—Not Ready, Conditional, or Ready for Controlled Pilot—so security, risk, and engineering teams can identify control gaps before deployment.
AI governance turns controls into an operating model
ISO/IEC 42001 provides the organizational framework for establishing, implementing, maintaining, and continually improving an Artificial Intelligence Management System (AIMS). It does not replace technical security controls. It connects AI governance, Responsible AI, AI risk management, and GRC with the organization’s AI inventory, approved use, risk ownership, accountability, monitoring, evidence, and continual improvement.
In practical terms, assume that a trusted agent can act incorrectly. Design boundaries, decision rights, evidence, and containment paths before granting it operational authority.
What security leaders need to detect next
Much of my incident-response work has focused on adversaries who first had to gain unauthorized access. Agentic systems change the evidence surface. A trusted identity may act on a hostile document while every individual log entry remains authorized. Security teams will need to correlate prompts, source documents, model decisions, tool calls, identity activity, and downstream operational effects as one incident chain.
Organizations are assigning operational authority to AI agents faster than they are adapting identity governance, detection engineering, incident command, and forensic readiness. Security leaders who close that gap early will gain the value of agentic automation without surrendering control of the systems it can change.
The company and incident are a composite designed to show how several control failures can compound. The mechanisms are real; no product weakness or working payload is described. Standards are referenced rather than reproduced. Validate architecture, permissions, product behavior, and regulatory obligations in your own environment before making production changes.
