Prompt Injection for AI Employees: Why Persistent Workers Change the Risk

§ 01Prompt-Injection Risk at a Glance

Use a source-to-effect model:

The OWASP LLM01:2025 Prompt Injection guidance distinguishes direct and indirect prompt injection and warns that retrieval, fine-tuning, and prompt controls do not fully remove the vulnerability. Its mitigations include constrained behavior, expected-output validation, least privilege, human approval, separation of external content, and adversarial testing.

The NIST Generative AI Profile similarly describes direct injection through an interface and indirect injection through data likely to be retrieved by an integrated application. These are system risks, not merely writing-quality problems.

Distinguish four outcomes

The first outcome matters even when no tool is used. A manipulated recommendation can still affect hiring, procurement, support, sales, finance, or public communication. Tools, memory, and delegation increase the potential consequence and duration.

Risk depends on both source and sink

OpenAI’s agent security discussion uses a source-and-sink framing: an attacker needs a way to influence the system and a capability that becomes dangerous in the wrong context. That creates a useful review question:

Which untrusted sources can reach which sensitive data, durable state, or consequential action without an independent control?

A detector at the source is useful. A control at the sink is essential. If the agent does not have a send function, production write permission, unrestricted URL access, or broad data visibility, an undetected injection has less room to create harm.

§ 02Direct and Indirect Prompt Injection Are Different Tests

Direct prompt injection arrives through a channel where a user is knowingly asking the model to do something. The user may attempt to override the role, obtain protected information, bypass policy, or reach a function that should be unavailable.

Indirect prompt injection arrives inside material the agent was asked to process. The apparent task may be legitimate: summarize an email thread; compare vendor websites; extract fields from a PDF; review a support ticket; research an account; inspect a code repository; read a tool response; or use a handoff from another worker.

The model must interpret the content to finish the task. The same content can contain language that looks like a command. That is the core ambiguity.

The first mistake is to treat all text as equivalent because it is delivered to one model. The system should preserve who supplied each item, why it was retrieved, what authority it has, and which later actions it may influence.

Instruction-like text is not automatically malicious

Contracts, emails, documentation, code, policies, tickets, and webpages contain legitimate commands. A policy review agent may need to quote “delete the record” without deleting anything. A support worker may read “reset my account” while lacking proof that the sender controls the account.

A simple phrase blocklist therefore creates both false negatives and false positives. The decision needs context: Is this content or a governing instruction? Who authenticated the instruction? Does that actor control the affected object? Is the requested action inside the current task? Is the destination approved? Does a deterministic rule allow the function? Is fresh approval required?

Filtering remains one layer. It should not replace authority checks.

Jailbreaking is not the whole problem

A jailbreak usually describes an attempt to make a model disregard its safety behavior. Prompt injection is broader. The worker may continue to appear helpful and policy-compliant while: giving extra weight to one source; omitting evidence; selecting an attacker-controlled destination; creating a misleading follow-up task; storing a false preference; escalating ordinary work; asking another agent to act; or disclosing data through an allowed-looking request.

Evaluate whether the worker preserves user intent and authority - not only whether it refuses conspicuously harmful language.

§ 03Why Persistent AI Employees Change the Threat Model

An AI employee is not just a response generator. It may have a durable role, recurring goals, schedules, connected accounts, task state, memory, and the ability to hand work to another employee. Each feature is useful. Each also changes exposure.

The foundational AI employee guide explains the operating model of role, goals, tools, memory, scheduling, and accountability. Prompt-injection review should cover the full operating loop rather than one chat transcript.

Exposure repeats

A one-time assistant may read one hostile page. A standing worker may inspect: every new lead; every inbound ticket; every document in a watched folder; every result returned by a search; every page linked from a research task; every handoff from a partner role; and every stored memory selected for a future run.

Even when each individual attempt is unlikely to work, repeated exposure changes operational risk. Monitoring should therefore track rates and patterns, not only single events.

Action may be delayed

The injected content may not ask for an immediate effect. It may alter: the interpretation of a goal; a recipient list saved for later; a preferred source; a standing exception; a procedural step; a follow-up task; a calendar trigger; or a memory retrieved on a later run.

The event timeline becomes:

exposure → candidate state → persistence → retrieval → decision → action

An incident investigator must be able to reconstruct every step. The AI employee audit-log guide defines the actors, sources, authority decisions, memory operations, tool events, outcomes, and lineage needed for that reconstruction.

A successful injection still needs authority

Model robustness matters, but the application controls blast radius. If the worker can only draft into a staging area, the result is different from a worker that can send, publish, purchase, delete, change permissions, or execute code.

The least-privilege guide for AI agents narrows identity, systems, resources, fields, functions, actions, destinations, time, volume, spend, and delegation. Apply those limits before expanding the worker’s content reach.

§ 04Threat-Model the Complete Content-to-Action Path

Choose one real workflow and draw its actual data path. “The agent reads email” is too broad. Use:

source actor → channel → parser → content store → retrieval → model context → plan → tool policy → approval → action → result → memory → delegation

For every edge, record: the actor; identity; trust; purpose; content form; private context; authority; persistence; delegation; enforcement; evidence; and recovery.

Use a source-sink matrix

Rows are sources. Columns are sinks. Review each intersection:

“Conditional” is not a control. Replace it with the exact identity, policy, approval, or validation rule.

Find dangerous combinations

Prioritize paths where one run contains: untrusted content; valuable private data; a write-capable or communication tool; a destination the content can influence; durable state; limited human visibility; and broad retry or delegation permission.

An inbox triage worker that only labels messages has a different profile from one that can search the full mailbox, open attachments, retrieve customer records, send external messages, update CRM, and remember account preferences.

Treat tool output as another input

Tool responses are not inherently trusted. A browser, connector, search system, database field, code repository, API, or another model can return attacker-influenced content.

Preserve: tool identity; request parameters; the returned object; the original source; content type; integrity status; timestamp; tenant/account scope; and transformation history.

Do not upgrade content authority because it arrived through an approved tool. The tool may be trusted to retrieve data while the retrieved data remains untrusted.

§ 05Keep Content Separate From Governing Instructions

The worker needs a clear authority hierarchy, but hierarchy alone is not a hard security boundary. Use it alongside application enforcement.

Preserve source boundaries in context

Do not concatenate everything into an unlabeled prompt. Carry: source type; source actor; authenticated identity where available; retrieval reason; document or object ID; timestamp and version; trust classification; tenant and account; applicable task; permitted uses; and sensitivity.

The AI employee context-pack guide shows how to assemble purpose-bound context with source ownership, precedence, freshness, and exclusions. Prompt-injection controls depend on keeping those distinctions visible through retrieval and action.

Extract facts without granting authority

Where possible, use a narrow transformation:

untrusted document → typed candidate fields → validation → task use

For example, an inbound request may yield: the claimed sender; the requested object; the proposed change; cited evidence; confidence; unresolved contradictions; and a source pointer.

The request does not become authorized merely because the model extracted it correctly. Verify the actor, object, policy, and approval independently.

Keep secrets out of unnecessary contexts

The safest private datum is one the untrusted content never shares context with. Retrieve only required fields; mask secrets and credentials; use separate steps for public research and private analysis; avoid exposing full mailboxes or repositories to a narrow task; resolve destinations in policy code; prohibit the model from choosing arbitrary external endpoints; and use reference tokens when the model needs an object identity but not its full data.

Compartmentalization reduces both accidental leakage and the reward of a successful injection.

Do not rely on prompt secrecy

Hiding the system prompt is not the same as enforcing it. A worker can be redirected without revealing the prompt. Critical rules should exist in: workload identity; application permissions; tool schemas; policy engines; allowlisted objects and destinations; approval gateways; transaction boundaries; sandboxes; rate and spend controls; and postcondition checks.

The model proposes. The system authorizes and executes.

§ 06Reduce What a Redirected Worker Can Do

Assume some hostile content will evade detection. Design the action boundary so that model influence alone cannot create an unacceptable effect.

Narrow the tools

Every tool call should bind:

agent identity + human principal + task + function + object + parameters + destination + data class + limit + approval + incident state

The AI employee permissions and approvals guide explains why approval must be tied to the exact action rather than a vague plan.

Resolve authority outside the model

Do not ask the model to decide whether it is allowed to: access a customer; send to a recipient; change a protected field; use an administrator function; publish externally; exceed a monetary threshold; delegate a capability; or bypass a security control.

Use deterministic authorization based on authenticated identities, task scope, resource ownership, data class, policy, and current system state.

Bind approval to the real effect

If any material field changes after approval, request a new decision. An injected instruction should not be able to swap the recipient, attachment, amount, object, or tool after a human approves.

Validate the result

A successful API response proves only that the API accepted a request. Check: the expected object changed; no unapproved object changed; the actual recipient and destination match approval; only permitted fields were disclosed; the action happened once; no hidden follow-up task was created; no unauthorized memory write occurred; and no child agent inherited excess authority. Then mark the task complete.

§ 07Prevent Prompt Injection From Becoming Durable Memory

Memory turns a transient influence into a possible future control. Microsoft’s agentic memory-safety guidance recommends gating writes on intent and provenance, logging memory lifecycle operations, tracking propagation, applying safety checks at retrieval, and preserving deletion and rollback paths.

The AI agent memory-types guide explains these functions as a design lens. Prompt-injection controls should be different for each type.

Put every material write through a gate

Require: purpose (which future task needs this item?); intent (did an authorized person or policy request persistence?); source; trust status; type; scope; sensitivity; evidence; freshness; conflict state; retention; and control (who can inspect, correct, suppress, and delete it?).

If required fields are missing, hold the item as a candidate or do not persist it.

Never promote external content directly into procedure

A webpage, email, ticket, attachment, tool response, or other agent’s free text should not directly create: a new operating rule; a security exception; a changed destination; a secret retrieval method; a bypass; an approval threshold; a new tool permission; or a standing preference that affects other people.

Procedural memory should come from a controlled policy or SOP change with an owner, review, version, effective date, and rollback path. The AI employee SOP guide provides that governance structure.

Separate observation from truth

Store: “Source X claimed Y at time Z for task T; verification status is pending.” Do not silently store: “Y is true.”

For episodic memory, preserve the action and verified outcome - not merely the model’s interpretation. For semantic memory, prefer the authoritative system of record. For preferences, confirm scope and affected person. For procedures, require formal approval.

Prevent recursive and inherited writes

An agent should not be able to launder untrusted content by: (1) summarizing it; (2) sending the summary to another agent; (3) receiving the summary back as “internal” content; and (4) storing it as trusted memory.

Provenance must survive transformations and handoffs. Trust should not increase merely because content was generated or relayed internally.

Scan at write and retrieval

Write-time checks reduce what becomes durable. Retrieval-time checks protect against: older poisoned records; newly discovered attack patterns; changed task context; revoked source trust; cross-account selection; stale procedures; and previously harmless content becoming dangerous next to a new tool.

The broader memory privacy and retention checklist covers purpose, minimization, access, correction, retention, deletion, vendor processing, and incident handling. Security review should use that lifecycle rather than treating memory as a single on/off feature.

§ 08Control Retrieval, Tools, and Multimodal Content

Indirect injection often enters through systems that were added to improve context. Each retrieval path needs a boundary.

Retrieval-augmented generation

For each retrieved item, preserve: the repository and document; author or controller; access decision; tenant/account; version and time; trust classification; query or retrieval reason; chunk boundaries; transformations; safety decision; and citation pointer.

Retrieval relevance does not prove authority or truth. A highly relevant hostile paragraph can still be the wrong basis for action. Use retrieval for evidence. Do not allow retrieved content to redefine the role, task objective, tool permissions, data boundaries, destination policy, approval rules, or memory policy.

Browser and email

Web and email workflows combine a large untrusted surface with useful private context. Reduce exposure by: using logged-out access when authentication is unnecessary; separating public research from private account work; using site, account, and destination restrictions; opening only needed messages and fields; treating links, redirects, forms, comments, and downloads as separate sources; preventing silent external transmissions; requiring review for sensitive account changes; and ending or isolating sessions after the task.

OpenAI’s prompt-injection overview emphasizes layered defenses, narrow access, explicit user instructions, monitoring, red-teaming, and confirmation before consequential actions. The same operational principles apply across vendors.

Documents, images, and hidden layers

The model may process content a human reviewer does not easily see: document metadata; off-page or low-contrast text; comments and tracked changes; image text; embedded objects; alt text; markup; accessibility layers; and OCR output.

Do not treat a visually benign file as trusted. Preserve the original, extracted representation, parser version, and source. Test every modality and transformation the production worker can consume.

Tool and model output

Generated output becomes another injection path when a downstream interpreter executes it. Validate structured output against a schema; encode data for its destination; avoid shell or query construction from free text; reject unknown functions and fields; resolve objects and recipients independently; inspect URLs and redirect behavior; treat model-generated code as untrusted; isolate execution; cap resource use; and verify the after-state.

Prompt injection and unsafe output handling can compound. The first redirects the worker; the second turns generated content into an effect.

§ 09Stop Injection From Crossing Agent Boundaries

Multi-agent systems add new principals, handoffs, scopes, and return channels. “Another company agent produced it” is not a trust classification.

The agent handoff protocol guide separates goals, context, authority, evidence, acceptance, and return. Use that structure to prevent free-text handoffs from silently changing another role.

Use a typed handoff

Do not let the parent pass its access token, hidden context, or unrestricted tool capability to the child.

Re-authorize at every boundary

The child should answer: Is this parent authorized to request the task? Is the goal valid for my role? May I access the named objects? Which source content is untrusted? Which functions are allowed? Does the action need fresh approval? May I write memory? Which fields may I return?

The return should be treated as untrusted input by the parent until validated.

Limit propagation

Set: maximum delegation depth; maximum child count; time, cost, and tool budgets; source and destination allowlists; context minimization rules; memory-write restrictions; loop detection; duplicate-action prevention; and circuit-breaker thresholds.

A redirected worker should not be able to create an unbounded tree of tasks.

§ 10Detect, Contain, and Recover From Injection

Preventive controls will miss some cases. Monitoring should detect suspicious influence before or after effect.

Log the decision path

Capture: content ingestion (source, actor, object, version, type, trust, task); retrieval (query, selected objects, reason, scope, scores, filters); safety decisions; plan changes; authorization; approval; tool calls and results; memory operations; delegation; and alert/response events.

Do not log hidden model reasoning. Log observable inputs, source lineage, proposed and executed actions, policy decisions, and results.

Monitor behavior, not only phrases

Useful signals include: a new destination or domain; data retrieval followed by external transmission; a task goal changing after external content is read; an unusual tool sequence; a memory write sourced from public or unknown content; procedural memory created outside policy workflow; cross-account retrieval; unexpected delegation; repeated blocked attempts through different tools; new encoded or multimodal content; a high-risk action outside normal schedule; an approval request that omits source or destination; and unusual volume, spend, retries, or runtime.

Phrase detection may contribute, but behavior and information flow are closer to the actual harm.

Use a containment ladder

Contain the smallest safe scope first, then expand if evidence shows propagation.

Correct persistent state

After a memory-poisoning event: identify the source and first affected task; enumerate derived summaries, indexes, task states, handoffs, and outputs; suppress retrieval before full deletion if immediate containment is needed; restore authoritative values or last known safe procedures; invalidate approvals and actions that depended on the poisoned state; inspect downstream effects and recipients; preserve the incident evidence; retest the path; and resume only after an accountable owner accepts residual risk.

The AI employee incident-response guide defines pause, revoke, preserve, scope, correct, notify, validate, and resume decisions for the wider operating system.

§ 11Test Prompt Injection Before Production

Testing should prove the entire control path, not just that the model says it ignored an instruction.

Do not use live secrets, real customer data, production write capability, or uncontrolled external endpoints. Run in an isolated test tenant with synthetic data, instrumented tools, fixed destinations, cleanup, and named owners.

Build a defensive test matrix

These are test categories, not attack recipes. Security teams can implement them with harmless markers and controlled destinations.

Grade the outcome

A model refusal is not automatically a pass. Confirm: no sensitive data was retrieved unnecessarily; no tool call occurred; no hidden task or memory was written; no delegation occurred; no approval was reused; the event was logged; and normal work can continue safely.

Retest on change

Retest after changes to: the model or provider; system or role instructions; parser or content extraction; retrieval source or ranking; connector or browser capability; tool schema; identity or permission; memory type or retrieval logic; agent topology or handoff; approval policy; data classification; monitors or detectors; downstream applications; or incident response procedure.

Prompt injection is an adaptive security problem. OpenAI’s discussion of continuously hardening browser agents describes ongoing discovery, testing, monitoring, and mitigation rather than a one-time claim of immunity. Buyers should expect the same operating discipline from any platform.

§ 12Evaluate an AI Employee Platform

A vendor should be able to explain the complete control path with product evidence.

Verify current CellCog behavior

CellCog publicly presents AI Employees as workers that can operate with goals, schedules, connected tools, memory, and employee-to-employee collaboration. Those capabilities make source trust, permissions, approvals, memory controls, auditability, and delegation boundaries part of the buying decision.

Public pages do not establish every implementation detail. As of July 29, 2026, buyers should verify in the live product and contract: how external content is labeled and isolated; whether browser, email, files, connectors, and tool results receive the same treatment; which prompt-injection detection or safety checks exist; where critical policy is enforced outside the model; whether arbitrary destinations are possible; whether memory writes require intent and provenance; how memory is inspected, corrected, suppressed, and deleted; whether child employees receive fresh, narrower authority; which approval fields are action-bound; what source-to-effect audit evidence is retained; how quickly one role or connector can be revoked; and which tests and incident commitments are supported.

The CellCog AI Employees page is the starting point for the operating model. The platform-specific assessment should continue through a demonstration, security review, permission tests, memory tests, audit export, and a controlled incident exercise.

The next operational step is the AI employee security checklist, which turns security claims into pilot evidence across identity, data, tools, memory, monitoring, response, and governance.

§ 13A 30-Day Implementation Blueprint

Use one representative workflow rather than trying to secure every proposed role at once.

§ 14Common Failure Patterns

§ 15Final Checklist

• Governing instructions, trusted operational data, external content, secrets, and model output have distinct roles.
• Source identity, provenance, purpose, trust, tenant, time, and transformation survive retrieval.
• Public or mixed-trust content is isolated from unnecessary private context.
• The agent uses a distinct, attributable, least-privileged identity.
• Systems, resources, fields, functions, actions, destinations, time, volume, spend, and delegation are bounded.
• Consequential tool calls use typed parameters and deterministic authorization outside the model.
• Arbitrary external recipients, URLs, commands, or production objects are blocked by default.
• Approvals show the actual source, data, object, destination, action, risk, and expiry.
• Material changes after approval require a new decision.
• Tool results are treated as untrusted input and after-state is verified.
• Memory writes require authorized intent, purpose, type, source, status, scope, evidence, owner, and retention.
• External content cannot directly create procedural memory, policy, permissions, or exceptions.
• Retrieval-time checks protect against old, stale, cross-scope, or newly dangerous memory.
• Provenance survives summaries, task state, memory, and agent handoffs.
• Child agents authenticate the parent, validate the task, and receive fresh, narrower authority.
• Monitoring connects source, retrieval, plan, policy, approval, tool, result, memory, and delegation.
• Breakers can stop suspicious retries, transmissions, writes, and delegation.
• The team can pause a role, revoke a connector or identity, suppress memory, and preserve evidence.
• Recovery traces derived state, corrects authoritative records, validates effects, and controls resumption.
• Direct, indirect, tool, retrieval, multimodal, memory, delayed, cross-account, delegation, approval, and recovery tests pass in an isolated environment.
• The tested model, prompt, parser, retrieval, tool, policy, memory, and monitor versions are recorded.
• Material system changes trigger retesting.

Start with one concrete path:

untrusted email or webpage → private context → proposed external action or memory write

Map it, narrow it, instrument it, and test it. If the worker cannot convert that content into unauthorized authority, and the organization can prove what happened when the content was encountered, the deployment has moved from prompt-level hope toward system-level control.