Pre-Task Authority

Expanded Definition

Pre-task authority describes a narrow but important startup window in which attacker-controlled content can shape what an AI agent does before its full trust boundary is active. In practice, the risk sits around bootstrap phases such as startup configuration, sandbox initialisation, helper process launch, or early orchestration logic, where decisions may be made before prompt-level controls are even relevant.

The boundary matters because agentic systems often assemble their operating context in stages. If untrusted input can influence those early steps, the attacker can steer execution paths, permissions, or environment setup before the system reaches its intended guardrails. That makes pre-task authority different from ordinary prompt injection, which typically acts after the agent is already running. It is also different from general “startup hardening” because the key issue is not just secure bootstrapping, but whether untrusted content can get a foothold in the pre-execution chain.

A useful way to think about the term is as a trust-order problem: which controls are in force first, and which inputs are able to affect them? For agentic AI, that distinction can determine whether a compromise becomes a harmless misdirection or a control-plane issue.

Examples and Use Cases

• An agent reads a task package that includes a startup directive, and that directive changes the sandbox policy before the agent’s normal policy checks are loaded.
• A helper process is spawned from content received at launch, and the process inherits environment variables or file paths that alter later tool access.
• A bootstrap script consumes attacker-influenced configuration and rewrites the agent’s initial permissions, workspace, or model-routing settings.
• An orchestration layer resolves dependencies from untrusted content before the agent fully establishes its trust boundary, allowing early-stage control over execution order.
• A plugin or extension is activated during startup and receives more influence than it would after the agent’s runtime controls have settled.

These patterns matter most when the system assumes “the agent will check later.” In pre-task authority scenarios, later checks may be too late because the initial execution context has already been shaped.

Security Implications

When pre-task authority is present, the security problem is temporal as much as technical. The attacker is not trying to win a normal prompt exchange, but to influence the conditions under which the rest of the system begins operating. That can weaken sandboxing, widen tool access, redirect execution into unsafe helper paths, or create a false sense that runtime controls are protecting a state that was already contaminated at startup.

This class of weakness is especially damaging because it can blur ownership between configuration, orchestration, and runtime security. Teams may inspect prompts, model outputs, and tool logs while missing the earlier stage where the decisive change occurred. A common operational symptom is that the agent behaves “correctly” according to later policy checks, yet still launches with altered context, incorrect defaults, or unexpected execution dependencies.

For that reason, pre-task authority is best treated as a control-boundary issue. If the trust boundary is established too late, the system may be defending the wrong phase of execution.

Security, Operational and Governance Implications

Pre-task authority is a strong reminder that agentic AI security is not just about what happens after a prompt is processed. Governance has to cover startup sequence, orchestration ownership, and which components are allowed to shape initial execution state. If those early steps are not tightly controlled, defenders can end up protecting the agent while leaving the launch path exposed.

Operationally, this means the highest-risk code is often the code that runs first, not the code that runs longest. Pre-task authority can also create supply-chain and integration exposure when launch-time inputs come from templates, helper services, or automation hooks that were assumed to be “just plumbing.” In practice, those paths may become the real trust boundary.

The most useful practitioner mindset is to ask whether a piece of content can affect the system before policy is active, not just after. That question changes how you review startup flows, bootstrap dependencies, and early-stage execution permissions in agentic environments.

Related resources from NHI Mgmt Group

• What breaks when filing authority is not pre-assigned for CRA reporting?
• Task-Scoped Authority
• What is the difference between identity governance and authority governance?
• What is the difference between role-based access and task-scoped access for AI agents?