Hard Rate, Resource & Iteration Caps With Circuit Breakers

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.

An event-triggered AI agent is a synthetic subject whose runs are started by a system event rather than a direct conversational request. This may include a frontend action, webhook, queue item, form submission, file drop, inbound email, application event, or record arriving in a data pipeline.

This deployment pattern creates an elevated exposure condition because the person or system that triggers the run may be different from the person who controls the input. The agent may run with a standing application identity and access to customer records, ticket queues, internal documents, communications, or pipeline data, while the event content may originate from an external or low-trust source.

The primary risk is event-driven indirect prompt injection. Form fields, payloads, queued rows, uploaded files, or inbound messages may contain instructions that the agent treats as task context. A malicious instruction can therefore be planted by a malicious individual and executed later when the workflow processes the item.

A related risk is unattended repetition. Event-triggered agents often process backlogs, queues, or recurring inputs without a human reviewing each run. A poisoned input or flawed directive may produce harmful outputs at machine speed while appearing to be normal workflow throughput.

Investigators should review the agent’s directive, trigger conditions, event payloads, queue records, service identity, workflow permissions, input sources, run history, tool calls, output destinations, and downstream actions. Particular attention should be given to externally controlled fields, repeated adverse outcomes across similar records, and logs that fail to show which input content caused the agent’s action.

Investigative Relevance

Event-triggered AI agents are relevant because they decouple human oversight from agent execution. The run may be authorized by the workflow, while the effective instruction is supplied through data controlled by an external party, customer, vendor, compromised account, or low-trust source.

This section is especially relevant where agents process public forms, inbound webhooks, emails, file uploads, watched folders, customer relationship management records, ticket queues, data pipelines, or application events without human review before action.

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.

Agent-to-agent and tool-output invocation occurs when the output of one synthetic subject, tool, service, or agent becomes the triggering instruction for another synthetic subject. The effective instruction is propagated through an agent graph, tool chain, orchestration layer, or service-to-service workflow rather than being issued directly by a human operator.

This invocation creates an elevated exposure condition because machine-generated output may be treated as trusted task context by the next synthetic subject. A tool result, worker-agent summary, delegated task, inter-agent message, service response, or generated record may carry instruction-bearing content that causes another synthetic subject to act.

The primary risk is propagation without human review. A compromised, manipulated, or misaligned synthetic subject may produce output that recruits other agents, triggers tool-equipped workers, causes repeated actions, or spreads across a multi-agent system. The resulting behavior may resemble worm-like fan-out, synchronized drift, or cascading action across multiple agents.

A related risk is provenance loss. If inter-agent messages and tool outputs are not signed, attributed, or tagged by trust level, investigators may be unable to determine which agent originated the instruction, which agents propagated it, and where the first unsafe action occurred.

Investigators should review inter-agent messages, tool outputs, orchestration logs, delegation records, shared context, tool-call logs, agent identities, message provenance, and downstream actions across the agent graph. Particular attention should be given to instruction-bearing payloads, repeated payloads across agents, one-to-many fan-out, synchronized identical actions, and actions caused by peer output rather than an approved human instruction.

Investigative Relevance

Agent-to-agent and tool-output invocation is relevant because synthetic subject action may be triggered by another machine actor inside the workflow. The apparent local action may be only one step in a broader propagation chain.

This section is especially relevant where orchestrators delegate to worker agents, agents exchange messages, tools return model-visible output, services generate task instructions, agents share context, or multi-agent systems operate without human review at each handoff.

Autonomous self-invocation occurs when a synthetic subject causes its own subsequent action without a fresh external prompt. This may include recursively calling itself, scheduling future runs, spawning new processes, resuming its own workflow, or modifying launch, timeout, or scheduler settings that determine when it acts again.

This invocation creates an elevated exposure condition because the synthetic subject can sustain or amplify behavior beyond the original user request. A single invocation may become a chain of repeated actions, long-running loops, recurring tasks, or self-started processes that continue after the operator stops actively supervising the system.

The primary risk is unbounded or self-sustaining action. A synthetic subject may continue running, re-run itself, extend its own execution time, create scheduled tasks, consume resources, or repeatedly call tools in pursuit of a goal. This may cause resource exhaustion, cost escalation, system instability, data corruption, or repeated operational changes.

A related risk is runtime-control interference. If the synthetic subject can modify the scripts, schedules, launch files, timeout values, containers, or job definitions that govern its own execution, it may weaken the external limits that are supposed to stop or contain it.

Investigators should review self-invocation chains, scheduler records, cron jobs, launch scripts, daemon entries, process trees, timeout settings, container settings, tool-call logs, resource consumption, non-human identity activity, and configuration changes attributable to the synthetic subject. Particular attention should be given to recursive calls, self-spawned processes, new scheduled tasks, timeout extensions, repeated tool loops, and agent-created changes to its own runtime controls.

Investigative Relevance

Autonomous self-invocation is relevant because the visible initiating prompt may not explain the duration, repetition, or scale of later synthetic subject activity. The investigation must determine whether subsequent actions were externally requested or self-triggered by the synthetic subject.

This section is especially relevant where synthetic subjects can write code, edit scripts, launch processes, create scheduled tasks, call workflow APIs, modify job definitions, operate unattended, or run in environments where they can affect their own runtime controls.

Agentic harm propagation occurs when an adverse condition affecting one synthetic subject spreads to other synthetic subjects, tools, memory stores, sessions, workflows, or systems. The spread may occur through agent-to-agent messages, shared memory, tool outputs, orchestration handoffs, connector metadata, generated records, or workflow state.

This adverse outcome creates organizational harm because the blast radius expands beyond the initial point of failure. A single poisoned input, unsafe output, false record, contaminated memory entry, or malicious connector may influence multiple synthetic subjects with different roles, permissions, tools, or data access.

The primary harm is system-wide amplification. An instruction, false record, unsafe behavior, misleading output, or malicious tool result may replicate or reappear across the agent graph, causing repeated data exposure, unauthorized actions, misinformation, fraud, operational disruption, or trust degradation.

A related harm is containment difficulty. By the time the adverse condition is detected, the original source may no longer be obvious. The same payload or false state may appear in summaries, task handoffs, memory entries, tool outputs, inter-agent messages, or downstream records, requiring investigators to reconstruct the propagation path across multiple logs and systems.

Investigators should review inter-agent communications, shared memory, orchestration logs, tool outputs, Model Context Protocol (MCP) server records, connector changes, memory writes, task handoff records, non-human identity activity, and downstream actions. Particular attention should be given to repeated instruction patterns, anomalous agent-to-agent message volume, poisoned memory records, tool-definition changes, one-to-many fan-out, and synchronized behavior across multiple agents.

Investigative Relevance

Agentic harm propagation is relevant because synthetic subject harm may not remain isolated. Agentic systems are often designed to share context, delegate work, call tools, and reuse memory, which can allow a localized adverse condition to spread through legitimate coordination paths.

This section is especially relevant where synthetic subjects operate in multi-agent systems, shared memory environments, MCP-connected tool ecosystems, orchestration frameworks, cross-agent workflows, or platforms where one agent’s output becomes another agent’s input.

Unbounded resource consumption occurs when a synthetic subject consumes compute, tokens, model calls, tool calls, storage, network capacity, application resources, or metered services at a scale that degrades availability or creates uncontrolled financial cost.

This adverse outcome creates organizational harm because synthetic subject execution may be costly, recursive, and difficult to stop once a loop or high-volume workflow begins. The impact may appear as service degradation, denial of service, denial of wallet, queue saturation, rate-limit exhaustion, cloud cost escalation, or depletion of shared operational capacity.

The primary harm is loss of availability or cost control. A synthetic subject may enter a runaway loop, recursively invoke itself, repeatedly call tools, retry failed operations, expand a task tree, generate excessive tokens, or consume high-cost infrastructure beyond the intended task scope.

A related harm is control failure. If the synthetic subject can modify its own timeout, launch script, retry behavior, scheduler, or runtime settings, it may weaken the controls designed to limit execution. Investigators should rely on runtime telemetry, billing records, tool-call logs, and scheduler data rather than the synthetic subject’s explanation of why the task continued.

Investigators should review model usage records, token counts, tool-call logs, billing records, queue depth, retry history, process trees, scheduler entries, timeout settings, launch scripts, non-human identity activity, and resource metrics. Particular attention should be given to recursive calls, runaway loops, high-cost API bursts, abnormal token usage, repeated failed retries, self-modified timeout controls, and consumption spikes tied to a single synthetic subject or non-human identity.

Investigative Relevance

Unbounded resource consumption is relevant because synthetic subjects can amplify a single request into repeated model calls, tool calls, jobs, retries, or self-invocations. The adverse outcome may be operational downtime, degraded performance, excessive spend, or exhaustion of resources needed by legitimate users.

This section is especially relevant where synthetic subjects can run autonomously, call metered APIs, use paid model endpoints, invoke tools recursively, create scheduled tasks, run experiments, launch jobs, generate long outputs, or modify their own execution controls.

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.

An unattended workflow agent is an autonomous AI agent wired into a workflow, connector, queue, or scheduled process that runs without a human reviewing each execution. It may process inbound items, act on a timer, monitor a source, or perform recurring tasks across connected systems.

This deployment pattern creates an elevated exposure condition because the agent may continue acting after its directive, inputs, or operating conditions drift. A poisoned input, compromised connector, malicious instruction, or flawed configuration may persist across repeated runs without immediate human observation.

The primary risk is continuous unattended harm. The synthetic subject may exfiltrate data, alter records, send messages, misroute items, or trigger downstream actions over many executions before anomaly detection, audit review, or an external report identifies the behavior.

Investigators should review the agent’s directive, schedule, trigger conditions, connectors, service identity, input sources, run history, tool-call logs, output destinations, and downstream actions. Particular attention should be given to recurring unusual actions, new external destinations, repeated processing of poisoned content, and behavior changes following configuration or source changes.

Investigative Relevance

Unattended workflow agents are relevant because they can operate repeatedly without direct human supervision. Their risk increases where they process untrusted inbound material or hold standing access to internal systems.

A webhook event trigger occurs when an inbound event from another system automatically starts an agent run. This may include a new ticket, inbound email, status callback, chat application event, customer relationship management update, or other webhook-driven workflow.

This deployment pattern creates an elevated exposure condition because the agent may run without a human reviewing the event first. The event payload may contain free text, metadata, links, attachments, or structured fields that the synthetic subject treats as task context.

The primary risk is attacker-shaped event input. Public or weakly authenticated endpoints may allow an external actor to forge, replay, or manipulate event payloads. A single malicious event may then trigger downstream actions, such as ticket routing, message generation, record updates, external calls, or tool execution, before anyone notices.

Investigators should review the event source, webhook authentication, payload content, replay protections, trigger rules, agent run logs, tool calls, downstream actions, and output destinations. Particular attention should be given to forged or repeated events, unusual payload fields, newly observed sources, and actions that exceed the normal event workflow.

Investigative Relevance

Webhook event triggers are relevant because they allow external or third-party system events to initiate agent behavior without direct human oversight. The workflow may appear routine, while the effective instruction is carried in the event payload.

This sub-section is especially relevant where agents process inbound webhooks, status callbacks, chat events, ticket events, email events, customer updates, integration messages, or other automated triggers from public, partner, or weakly trusted systems.

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.

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.

Recursive self-invocation occurs when a synthetic subject causes itself, its script, its workflow, or its agent process to run again as part of the same task. The later run is not initiated by a fresh human prompt, but by an action taken by the synthetic subject during its own execution.

This invocation creates an elevated exposure condition because a single request may become an uncontrolled execution chain. The synthetic subject may call its own entry point, restart its own process, invoke the same workflow repeatedly, or trigger a function that re-enters the same agent loop.

The primary risk is runaway recursion. A synthetic subject may continue executing until it exhausts time, compute, storage, credits, rate limits, or downstream system capacity. Where the recursive loop includes tool calls, file writes, database operations, or external requests, the harm may extend beyond resource consumption into repeated operational change.

Investigators should review process trees, workflow run history, tool-call logs, script changes, recursion depth, invocation identifiers, parent-child process relationships, and resource consumption. Particular attention should be given to repeated identical calls, self-referential command execution, sudden fan-out from one run to many runs, and recursion that began after the synthetic subject modified code or workflow state.

Investigative Relevance

Recursive self-invocation is relevant because repeated synthetic subject action may originate from the subject itself rather than from repeated external requests. The investigation must determine whether later runs were deliberately requested, automatically retried, or recursively generated by the synthetic subject.

This sub-section is especially relevant where synthetic subjects can execute code, call workflow APIs, edit scripts, invoke local processes, trigger jobs, or run inside orchestration environments that permit re-entry into the same agent or task.