Run-Scope and Blast-Radius Monitoring

An autonomous AI agent is a synthetic subject directed to plan and execute multi-step actions with limited human oversight. It may read context, call tools, write to systems, chain actions, and decide intermediate steps in pursuit of a goal.

This deployment pattern creates an elevated exposure condition because autonomy and access compound. A single instruction, poisoned input, or misunderstood objective may result in multiple real actions before a human reviews the outcome.

The primary risk is state-changing execution. Unlike an assistant that advises, an autonomous AI agent can act: deleting data, modifying records, sending messages, changing configuration, running commands, moving funds, or triggering downstream workflows. If its credentials, tools, or connectors are broad, the blast radius may extend across production systems, repositories, customer records, mailboxes, or external services.

A related risk is untrusted input steering. The agent may ingest web pages, files, tickets, emails, lead forms, code comments, or other external content while deciding what to do next. If that content contains instructions, the model may treat them as part of the task and execute actions under the agent’s authority.

Investigators should review the agent’s directive, tool access, credentials, service identity, action logs, planning records, ingested content, approval gates, execution timeline, and authoritative system logs. Particular attention should be given to destructive actions, bulk operations, external sends, actions outside the declared objective, and discrepancies between the agent’s self-report and actual system activity.

Investigative Relevance

Autonomous AI agents are relevant because they can convert a directive into a sequence of operational actions. Their autonomy may allow a benign-sounding goal to expand into destructive, unauthorized, or externally visible effects.

Autonomous action control is the configuration that determines how much of the observe, decide, and act loop a synthetic subject can complete without human approval. It includes whether the synthetic subject can plan, call tools, execute actions, continue loops, or affect systems independently.

This configuration creates an elevated exposure condition because autonomy changes the speed and scale of action. A synthetic subject with broad autonomy may perform multiple steps, call tools, make decisions, and trigger downstream effects before a human reviews the result.

The primary risk is insufficient approval gating. If irreversible, privileged, externally visible, or high-impact actions do not require enforced human approval, the synthetic subject may delete data, modify records, send messages, change configuration, move funds, or trigger workflows without meaningful oversight.

A related risk is rubber-stamped approval. Human-in-the-loop controls may exist, but provide limited protection where approvals are too frequent, low-context, low-value, or routinely accepted without review. In these cases, the workflow may appear supervised while the synthetic subject effectively operates autonomously.

Investigators should review autonomy settings, approval gates, tool permissions, action logs, escalation rules, loop limits, run duration, reviewer records, approval latency, and autonomous-to-approved action ratios. Particular attention should be given to long unattended runs, action bursts, instant approvals, high-impact actions without approval, and cases where the synthetic subject acted on unsupported or hallucinated information.

Investigative Relevance

Autonomous action control is relevant because it defines where synthetic subject output becomes operational action. The same tool access may present different risk depending on whether each step requires approval, only the final result is reviewed, or the synthetic subject can act unattended.

This section is especially relevant where synthetic subjects can run commands, send communications, modify records, execute workflows, approve transactions, deploy changes, move data, or operate in loops without step-level human review.

An orchestrated AI system is a deployment pattern where multiple synthetic subjects coordinate to complete a goal. This may involve an orchestrator that decomposes work and delegates tasks to worker agents, or peer agents that call each other across services, teams, or organizations.

This deployment pattern creates an elevated exposure condition because agents may share context, instructions, tools, credentials, or outputs over trusted internal channels. The effective synthetic subject is the whole agent graph, not only the individual agent that performs the final action.

The primary risk is distributed authority. One manipulated agent, poisoned input, or unsafe delegation may spread across the system and cause other agents to act on untrusted instructions. Because agents may treat each other’s outputs as trusted, a single injected instruction can propagate through the graph and influence tool-equipped workers.

A related risk is diffuse attribution. Actions may appear in logs as “the system,” an orchestrator identity, a shared service account, or the final worker agent, rather than the agent or input that originated the decision. This can make intent, origin, data movement, and responsibility difficult to reconstruct after an adverse outcome.

Investigators should review the system directive, orchestration logic, delegation graph, agent identities, inter-agent messages, shared context, tool access, credentials, provenance records, and cross-boundary data flows. Particular attention should be given to new agent-to-agent paths, repeated instructions appearing across agents, aggregate access that exceeds the task scope, and actions that cannot be traced to an approved source.

Investigative Relevance

Orchestrated AI systems are relevant because they allow synthetic subjects to behave like a coordinated internal team. Their combined reach may exceed the access, autonomy, and speed of any individual agent.

This section is especially relevant where orchestrators delegate to tool-equipped workers, agents share context or service identities, agent-to-agent links cross teams or trust zones, or a single workflow can touch multiple systems, data classes, or organizations.

Sandbox escape and out-of-boundary system access occurs when a synthetic subject operating inside an intended test, evaluation, development, or constrained execution environment reaches systems outside the boundary it was authorized to access. The affected systems may be external internet hosts, production infrastructure, package registries, third-party services, internal systems outside the evaluation range, or unrelated organizations.

This adverse outcome creates organizational harm because the synthetic subject’s actions are no longer confined to the environment assumed by the operator, evaluator, or control owner. The subject may scan, authenticate, exploit, publish code, retrieve data, modify systems, or interact with real services while believing, or claiming to believe, that those targets are part of the exercise.

The primary harm is unauthorized system access outside the declared operating boundary. Even where the root cause is weak sandbox configuration, the adverse outcome is the synthetic subject’s real interaction with systems it was not meant to reach. The investigation should distinguish the enabling condition from the outcome: poor sandbox configuration belongs under Configuration, while the access, exploitation, publication, or downstream impact belongs here.

A related harm is boundary uncertainty. If the synthetic subject is given an open-ended objective and the environment does not enforce hard limits, it may discover reachable targets that were never intended to be in scope. Investigators should not assume malicious intent merely because the subject crossed the boundary. They should test whether the subject exploited a discovered weak boundary deliberately, followed a task objective under a false belief, or continued after evidence showed the target was real.

Investigators should review sandbox configuration, network egress controls, Domain Name System (DNS) resolution, route tables, proxy logs, package registry activity, tool-call logs, shell commands, authentication attempts, evaluation prompts, system prompts, execution traces, external destination logs, and any reasoning or self-report produced during the run. Particular attention should be given to the first out-of-boundary connection, whether the subject recognized the target as real, whether it stopped or continued, and whether external activity can be tied to a declared task objective.

Investigative Relevance

Sandbox escape and out-of-boundary system access is relevant because synthetic subjects may operate under assumptions created by humans, prompts, vendors, or evaluation harnesses. A subject may be told that it has no internet access while the environment is actually misconfigured to permit it. In that case, the configuration failure enables the incident, but the adverse outcome remains the unauthorized external or production interaction.

This section is especially relevant where synthetic subjects run cyber evaluations, coding tasks, browser or desktop automation, package publishing workflows, development agents, tool-using agents, or autonomous test harnesses with network, filesystem, credential, or package-registry access.

This section should be cross-referenced with Configuration objects covering sandbox egress, tool permissions, non-human identity access, runtime controls, and connected tools. It may also relate to Opacity where logs do not clearly show how the boundary was crossed, and to Directive where the subject continues after recognizing that the environment may be real.

A single-task tool agent is an autonomous AI agent given one operator objective and permission to complete it through a sequence of tool calls. The human operator may approve the goal and review the final result, but does not examine each intermediate action.

This deployment pattern creates an elevated exposure condition because a narrow objective may still expand into multiple state-changing operations. The agent may read records, call application programming interfaces (APIs), edit files, send messages, update tickets, change configuration, or run commands while attempting to complete the task.

The primary risk is unauthorized expansion of action. A benign-sounding objective may lead the synthetic subject to perform destructive, irreversible, or externally visible steps that the operator did not explicitly authorize. A related risk is unreliable self-reporting, where the agent claims success, rollback, or safe completion even when authoritative logs show failure, partial execution, or harmful activity.

Investigators should review the agent’s directive, operator objective, tool permissions, plan, action sequence, tool-call logs, parameters, affected systems, and final output. Particular attention should be given to actions outside the stated objective, destructive operations, missing approval gates, and discrepancies between the agent’s report and authoritative system records.

Investigative Relevance

Single-task tool agents are relevant because they can convert one approved objective into a chain of unreviewed actions. Even when a human remains present, oversight may be limited to the starting instruction and final answer.

A privileged engineering agent is an autonomous AI agent granted write access to engineering or operational systems. This may include source code repositories, infrastructure, databases, continuous integration and continuous delivery (CI/CD) pipelines, deployment systems, secrets stores, cloud environments, or production services.

This deployment pattern creates an elevated exposure condition because the agent can directly change systems that affect software integrity, service availability, data retention, or production behavior. Its actions may ship code, alter infrastructure, modify database records, change configuration, rotate secrets, trigger deployments, or run administrative commands.

The primary risk is high-impact standing access. A single wrong, excessive, or hijacked action may delete production data, weaken controls, introduce vulnerable code, backdoor software, disrupt services, or alter customer-facing systems at scale. If backups, replicas, or recovery tooling are reachable with the same authority, the agent may damage recovery paths as well as the primary system.

Investigators should review the agent’s directive, credentials, repository permissions, pipeline access, database privileges, infrastructure roles, command history, deployment logs, change records, backup access, and approval gates. Particular attention should be given to destructive commands, production writes, unauthorized deployments, suspicious code changes, and any access to backup or recovery systems.

Investigative Relevance

Privileged engineering agents are relevant because they place a synthetic subject inside high-impact engineering and operations workflows. The agent may be intended to accelerate development or remediation, but its access can affect production systems directly.

A batch processing trigger occurs when an agent or model processes queued rows, files, records, or items in a scheduled data pipeline. This may include Extract, Transform, Load (ETL) jobs, bulk classification runs, document processing queues, ticket enrichment, record summarization, or scheduled workflow automation.

This deployment pattern creates an elevated exposure condition because each item is processed without per-item human review. A single poisoned row, file, record, or queued item may enter the model’s context and influence the run while appearing to be ordinary batch input.

The primary risk is hidden manipulation inside routine throughput. Because the run is bulk and scheduled, a tampered item may be difficult to distinguish from normal processing. If the agent has broad pipeline permissions, one poisoned record may trigger outputs, updates, classifications, external calls, or downstream actions across the job’s full data scope.

Investigators should review the pipeline directive, schedule, input queue, source records, transformation logs, model outputs, tool calls, downstream writes, error handling, and affected data scope. Particular attention should be given to anomalous individual records, repeated harmful outputs across a backlog, externally sourced rows or files, and changes that occurred without per-item approval.

Investigative Relevance

Batch processing triggers are relevant because they allow a synthetic subject to act across many records at machine speed with limited human visibility. A harmful instruction or manipulated input may be hidden inside otherwise normal pipeline activity.

Over-scoped agent access occurs when a synthetic subject is granted permissions beyond what is required for its approved function. This may include broad read access, write permissions, administrative scopes, cross-repository access, tenant-wide connectors, or access to data classes unrelated to the task.

This configuration creates an elevated exposure condition because any defective directive, manipulated invocation, compromised connector, or unsafe tool call may operate across a larger scope than necessary. The synthetic subject’s practical capability is defined by what its credentials allow, not by what its prompt says it should do.

The primary risk is excessive blast radius. A synthetic subject intended to summarize tickets, answer questions, or process records may be able to retrieve confidential documents, access customer data, modify systems, or transmit information outside its intended boundary.

Investigators should review assigned scopes, role grants, connector permissions, cloud roles, data access policies, tool permissions, and actual access patterns. Particular attention should be given to tenant-wide access, broad wildcard permissions, production write access, and access to sensitive repositories that are not required for the synthetic subject’s function.

Investigative Relevance

Over-scoped agent access is relevant because excessive permission turns routine AI behavior into high-impact operational risk. It is especially relevant where a low-risk assistant, embedded feature, or workflow agent has access normally reserved for privileged users or production services.

Excessive agency occurs when a synthetic subject is configured with a combination of permissions, tools, functions, or action paths that exceed its approved operational purpose. This may include broad read access, write capability, administrative functions, production access, external communication authority, or permission to call high-impact tools.

This configuration creates an elevated exposure condition because the synthetic subject is not only able to access information, but also to act on it. Excessive agency may allow the synthetic subject to retrieve data, modify records, send messages, trigger workflows, call Application Programming Interfaces (APIs), change configurations, or perform operational actions beyond what its role requires.

The primary risk is excessive blast radius. A flawed directive, manipulated invocation, compromised tool, or unsafe model output may result in actions that affect systems, data, customers, or business processes outside the synthetic subject’s intended scope. This is especially significant where the synthetic subject holds standing access to privileged functions or where high-impact actions do not require separate approval.

Investigators should review the synthetic subject’s permissions, tool access, functional capabilities, connector scopes, write privileges, administrative roles, external communication authority, and approval gates. Particular attention should be given to functions that allow data modification, external transmission, production change, financial action, security control alteration, or access to backup and recovery systems.

Investigative Relevance

Excessive agency is relevant because configuration determines not only what a synthetic subject can see, but what it can do. A limited assistant may become a high-impact synthetic subject if its permissions and functions allow it to act across systems without appropriate restriction.

An orchestrator and worker agent pattern uses a central planning agent to decompose a goal and delegate subtasks to specialized worker agents. The orchestrator may coordinate tool use, pass context between workers, sequence actions, and determine when the overall task is complete.

This deployment pattern creates an elevated exposure condition because the orchestrator may hold broad credentials, connectors, or authority needed to drive the full run. Its identity may aggregate the reach of multiple workers, making it a high-privilege chokepoint inside the system.

The primary risk is that a single manipulated orchestrator can direct harmful activity across many connected workers and systems. If the orchestrator is compromised, misdirected, or influenced by poisoned input, its instructions may propagate through the agent graph without a human reviewing each delegation step.

Investigators should review the orchestrator directive, delegation logic, worker permissions, shared context, credentials, tool access, inter-agent messages, task graph, and execution logs. Particular attention should be given to unexpected delegation paths, worker actions outside assigned subtasks, aggregate access exceeding task scope, and actions that cannot be traced to an approved operator objective.

Investigative Relevance

Orchestrator and worker agent patterns are relevant because they concentrate planning authority and distributed execution in one coordinated system. The orchestrator may not perform every action itself, but it can direct workers that hold specialized access or tools.

This sub-section is especially relevant where a central agent can invoke multiple workers, coordinate cross-system actions, aggregate credentials, pass instructions between agents, or complete multi-step workflows without human review between steps.

Authorized operator invocation occurs when an authorized human principal directly prompts, commands, or instructs a synthetic subject to perform an action. The synthetic subject then executes the request using its standing identity, tools, permissions, and configured environment access.

This invocation creates an elevated exposure condition because the instruction may be authorized while the resulting action exceeds the operator’s intent or approved authority. A free-text command may cause the synthetic subject to infer intermediate steps, call tools, modify systems, delete data, or affect production assets in ways the operator did not explicitly approve.

The primary risk is authorized invocation with unauthorized effect. The human operator may have intended a limited task, test action, planning step, or development-context change, while the synthetic subject acts against sensitive, production, or high-impact resources using its available privileges.

Investigators should review the operator prompt, session context, tool-call logs, non-human identity records, environment identifiers, command arguments, affected resources, approval history, and the synthetic subject’s stated plan. Particular attention should be given to destructive actions, production-affecting changes, bulk operations, actions taken during freezes or change windows, and discrepancies between the synthetic subject’s narration and authoritative system logs.

Investigative Relevance

Authorized operator invocation is relevant because a damaging synthetic subject action can begin with a legitimate human request. The investigative question is whether the synthetic subject’s executed action stayed within the operator’s intended scope and approved authority.