Bot-Delegated TOCTOU

Expanded Definition

Bot-delegated TOCTOU describes a race condition created when an automated workflow checks a request, artifact, or policy state at one moment and then performs the action after that state has changed. The risk is not limited to classic software races. In modern delivery pipelines, bots, scripts, approval engines, and AI agents can all become the actor that performs the check and the actor that later executes the use, making the gap between those moments security-relevant.

In practice, the issue sits at the intersection of workflow automation and integrity assurance. A release bot may validate a commit hash, a build system may verify a package signature, or an agent may inspect a file path before invoking a tool. If an attacker can alter the target, dependency, or environment between those steps, the automation can faithfully carry out an untrusted action while still believing it was approved. The NIST Cybersecurity Framework 2.0 is relevant here because it emphasizes protecting data, assets, and workflow integrity across operational states.

Definitions vary across vendors when the term is applied to AI agents versus conventional CI/CD automation, but the core security idea is consistent: trust was established on stale context. The most common misapplication is treating a point-in-time approval as sufficient when the object, dependency, or execution environment can still change before the bot acts.

Examples and Use Cases

Implementing bot-driven approvals rigorously often introduces latency and extra verification steps, requiring organisations to weigh delivery speed against stronger integrity checks.

• A CI/CD bot checks a signed artifact, then later fetches the same package by mutable tag instead of immutable digest, allowing substitution before deployment.
• An agentic workflow validates a ticketed request, then uses a file path that an attacker swaps for a different payload before execution.
• A release automation system approves a merge commit, but the referenced branch is force-pushed before the build job starts.
• A secrets rotation bot confirms the target service, then rotates credentials after the service identity has been replaced or redirected.
• A cloud automation script verifies a template, then applies it after a linked dependency or container image has changed upstream.

These scenarios are especially important where automation bridges code review, identity, and execution. Guidance from NIST CSF and related integrity controls aligns well with the need to preserve the exact object being approved. In agentic systems, the same pattern can arise when an AI agent checks a prompt, URL, or tool target and then acts on a different version a moment later.

Why It Matters for Security Teams

Bot-delegated TOCTOU matters because automation often receives more trust than human operators, yet it can be easier to trick at machine speed. When teams assume that validation and execution are effectively the same event, they miss the attacker’s opportunity to alter inputs, replace artifacts, or redirect tool calls between those steps. That can lead to unauthorized code execution, poisoned deployments, compromised credentials, or policy bypass in systems that were believed to be governed by approvals.

This is particularly relevant in identity-heavy environments where non-human identities, service accounts, and AI agents are granted just enough privilege to move work forward. If those identities are allowed to act on mutable references, the integrity problem becomes an access problem as well. NIST Cybersecurity Framework 2.0 supports the broader practice of protecting system state and execution trust, while the same logic applies to NHI governance when bots are the ones making the final call.

Organisations typically encounter this issue only after a pipeline, approval flow, or agent action has produced an unexpected release or destructive change, at which point bot-delegated TOCTOU becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When does delegated access become too risky for AI agents?
• What is the difference between human delegated access and agentic access?
• When should a privileged account be marked as sensitive and cannot be delegated?
• What is the difference between delegated and autonomous MCP use cases?