Secure the handoff, not just the AI agent

The vulnerable object is the workflow's trust transition

Prompt injection describes how malicious intent enters an agent. It does not explain why a stranger's issue body can become shell execution, why a read-only tool can leak a secret, or why one low-privilege run can control the next. Those outcomes require a second event: a handoff where attacker-influenced material is relabeled, transformed, stored, or consumed with more authority than it had at entry.

Novee Security's August 6 Black Hat disclosure makes this distinction concrete. Its researchers tested default coding-agent workflows used by Anthropic, Google, and OpenAI on vendor repositories. The reported chains began with zero-privilege GitHub issue input and reached outcomes including runner code execution, credential exposure, downstream supply-chain risk, and persistent control through a writable instruction file. The vendors and affected designs differ. The repeated pattern is that a locally reasonable control stopped being sufficient after another component inherited its output or state.

That framing matters for engineering. “Sanitize the prompt” is an input tactic. “Run the model in a sandbox” is an execution tactic. “Ask a human” is a decision tactic. None states what happens when the sanitized input becomes a file, the sandbox writes to a shared checkout, a later job receives credentials, or a reporting feature publishes tool output. A system is only as constrained as the most permissive path across those transitions.

OpenAI's current prompt-injection guidance reaches a compatible conclusion from a different direction. It says fully developed attacks are not usually caught by classifiers that attempt to separate malicious and ordinary input. GitHub's Copilot cloud-agent documentation likewise acknowledges that issues and comments can contain injected instructions, while documenting character filtering, restricted internet access, security scanning, signed commits, and session logs. These controls reduce exposure. They do not make provenance disappear.

A five-stage attack can use only legitimate operations

The crucial step is number four. Novee's Codex example describes two agent passes in one job sharing a checkout. The first pass receives attacker-controlled issue data and can write within the workspace. A later invocation reads the default project instruction file from disk. Protecting .git, .agents, and .codex is sensible, but an unprotected instruction file can still turn a workspace write into future control. The current sandbox may enforce exactly what it promises while the next process inherits poisoned authority.

The July self-state paper generalizes this beyond one product. It models attacks on an agent's instruction, configuration, and memory layers across target, mechanism, granularity, and time. The study instantiates 43 concrete operations in a 23-cell matrix using legitimate filesystem behavior. Its tested defense stack combines access control on instruction and configuration state, workload-conditioned detection for memory, and backup for recovery. It also finds residual operations that look structurally similar to normal behavior at the operating-system level.

Another July paper introduces agent data injection. Instead of disguising malicious text as an instruction, an attacker supplies false security-critical metadata, resource identifiers, origins, or tool-response structures. A model may follow its system rules and still act on counterfeit data. This breaks a common defense assumption: separating “instructions” from “data” is useful only when the system can prove which data is authentic.

Three trust changes to search for

Model every handoff as an explicit security object

A useful handoff record binds six facts: producer identity, input provenance, artifact digest, schema, allowed consumer, and maximum authority. Add an expiration time because a safe artifact can become unsafe after policy, dependencies, or environment state changes. The consumer should verify the record independently rather than trusting a flag set by the producer.

apiVersion: agent.security/v1
kind: Handoff
metadata:
  id: issue-analysis-8472
  createdAt: 2026-08-10T01:20:00Z
  expiresAt: 2026-08-10T02:20:00Z
producer:
  identity: agent-intake@ci
  trustZone: untrusted-analysis
inputs:
  - uri: github://org/repo/issues/8472
    trust: untrusted
artifact:
  path: out/issue-analysis.json
  sha256: 8b1f...c940
  schema: issue-analysis.v3
consumer:
  identity: patch-planner@ci
  allowedActions: [read-artifact, propose-plan]
  deniedActions: [shell, network, repository-write, secrets]
attestation:
  signer: handoff-broker@platform
  policyVersion: agent-boundary-2026-08-10

This manifest is not security because it is YAML. It becomes a control only when a broker creates the record from observed state, signs it, and prevents the producer from changing the artifact afterward. The consumer verifies the digest and schema in a fresh workspace. Any later stage requesting more authority must create a new handoff and justify the upgrade.

Preserve taint at field level when practical. A title copied from an issue remains untrusted even after it appears inside a valid JSON document. A model-generated summary is derived from untrusted input; schema validation proves shape, not truth. The planner may quote it as data, but it must not interpolate it into a shell command, path, identity, network destination, or policy selector.

Do not use model confidence as a trust label. Confidence describes the model's own prediction, not the origin of a value. Provenance is established by authenticated systems, immutable references, signatures, and reproducible transformations.

Use separate identities, workspaces, and artifact lanes

Fresh means reconstructed from a verified source, not “delete a few suspicious files.” Never promote the same mutable checkout from untrusted analysis into patching or release. Copy only allowlisted artifacts through the broker. Recreate the repository from a pinned commit and verify that agent instruction files match the trusted tree before each invocation.

Make instruction paths immutable to lower-trust stages. Protect obvious directories and every file the harness reads as policy or instruction: AGENTS.md, CLAUDE.md, skill manifests, tool registries, MCP configuration, shell profiles, build hooks, editor settings, package-manager config, and agent memory. Maintain a product-specific inventory because new instruction sources appear as tools evolve.

Use distinct workload identities rather than one token with conditionally hidden fields. Environment-variable filtering is not equivalent to process isolation if another same-user process can read the parent environment. A “read-only” network method is not no-egress if the URL path, query, DNS request, cache, counter, or public report creates an attacker-observable channel. Treat network destinations as write surfaces unless proven otherwise.

Bind release to evidence. The release job should accept only a reviewed commit digest, a signed policy result, and a short-lived approval. It should not read issue text, model memory, or a patch-stage workspace. This breaks the common chain where untrusted narrative follows the artifact all the way to production.

Make authority upgrades deny-by-default

handoffs:
  defaults:
    preserve_untrusted_provenance: true
    require_fresh_workspace: true
    require_artifact_digest: true
    reject_unknown_fields: true
    max_age_minutes: 60

  rules:
    - from: untrusted-ingest
      to: analysis
      allow: [canonical-event]
      credentials: none

    - from: analysis
      to: patch
      allow: [signed-plan]
      require: [policy-check, human-task-owner]
      credentials: branch-scoped

    - from: patch
      to: release
      allow: [reviewed-commit]
      require: [tests, security-scan, reviewer-signature]
      credentials: short-lived-release

protected_state:
  - "**/AGENTS.md"
  - "**/CLAUDE.md"
  - ".git/**"
  - ".github/workflows/**"
  - ".codex/**"
  - ".agents/**"
  - "**/skills/**"
  - "**/*mcp*.json"

The enforcement engine should evaluate observed facts, not ask the same agent whether the handoff is safe. A small policy function can verify provenance and authority before spawning the next stage:

def authorize_handoff(handoff, artifact, consumer):
    verify_signature(handoff.attestation)
    assert now() < handoff.metadata.expiresAt
    assert sha256(artifact) == handoff.artifact.sha256
    validate_json(artifact, handoff.artifact.schema, reject_unknown=True)
    assert consumer.identity == handoff.consumer.identity
    assert requested_actions(consumer) <= set(handoff.consumer.allowedActions)
    assert workspace_is_fresh(consumer.workspace)
    assert protected_state_matches_trusted_commit(consumer.workspace)
    return issue_short_lived_identity(consumer, handoff)

Record denied attempts as first-class security events: unexpected protected-state writes, artifact digest mismatches, unknown schema fields, stale handoffs, consumer mismatch, authority requests above the declared ceiling, and reads of untrusted material inside a release stage. Logs must include state mutation and identity transitions, not only model messages.

Test the complete chain after every harness change

Normal evals ask whether an agent completes the task. A trust-handoff suite asks whether an attacker can shape later authority while the task still appears successful. Run both. Prompt refactors, tool updates, new allowlists, reporting features, caching, workspace reuse, or instruction discovery can change the security result without changing functional quality.

Keep adversarial cases in CI. A recent r/AI_Agents discussion described prompt-injection tests catching a regression after an ordinary prompt change, not a security feature change. That is the right mental model: instruction hierarchy and tool wiring are production code and deserve regression tests.

Failure modes that survive a good-looking security review

A practical deployment checklist

• List every untrusted trigger, including issues, comments, forks, documents, web pages, tickets, messages, and tool responses.
• List every instruction, configuration, memory, skill, hook, and tool-registry path read by each agent invocation.
• Draw each handoff and mark producer identity, consumer identity, mutable storage, credentials, network, and maximum action.
• Separate ingest, analysis, patch, review, and release identities; remove secrets from stages that do not need them.
• Use fresh workspaces at authority boundaries and reconstruct from pinned, verified commits.
• Pass only allowlisted, schema-valid, digest-bound artifacts through an enforcing broker.
• Keep untrusted provenance after summarization, validation, and serialization.
• Protect every agent-readable instruction path from lower-trust writes.
• Treat GET, DNS, reports, logs, counters, caches, and previews as possible egress channels.
• Bind human approval to the exact artifact digest, action, destination, identity, and expiration.
• Run functional and adversarial evals after prompt, harness, tool, policy, or dependency changes.
• Practice recovery: invalidate handoffs, rotate credentials, discard mutable state, and rebuild from trusted sources.

If a diagram contains one box labeled “agent,” expand it. The model, harness, tool broker, filesystem, memory, identity provider, CI runner, artifact store, and release system make different trust decisions. Most exploitable assumptions live between those boxes.

FAQ

What is an AI-agent trust handoff?

It is a transfer of data, state, instructions, or artifacts between components. The handoff is unsafe when attacker-influenced material gains trust, persistence, credentials, write permission, network reach, or execution authority after the transfer.

Is this just another name for prompt injection?

No. Prompt injection can start the chain. Data injection, malicious repository state, compromised tools, stale memory, and counterfeit metadata can produce the same handoff failure without a recognizable instruction. The model may behave consistently while the system supplies false trust facts.

Does a sandbox solve workspace poisoning?

A sandbox constrains the current execution. It does not automatically protect future invocations from files the current stage is allowed to write. Pair sandboxing with immutable instruction paths, fresh workspaces, separate identities, and digest-bound artifacts.

Should every stage require human approval?

No. Frequent low-information approvals create fatigue. Automate objective policy checks and reserve humans for consequential authority changes. When approval is required, bind it to exact evidence rather than a vague description.

Can we trust data after schema validation?

Schema validation proves shape. It does not prove origin, truth, or authorization. Verify authenticated provenance, enforce allowed values, retain untrusted taint, and independently resolve security-critical identifiers.

Sources and further reading

Current product facts, advisories, and research were checked on August 10, 2026. Vendor disclosures describe specific tested versions and configurations; verify current releases and advisories before operational decisions.

• Novee Security: Black Hat 2026 coding-agent findings and trust-handoff analysis
• GitHub Docs: risks and mitigations for Copilot cloud agent
• OpenAI: designing AI agents to resist prompt injection
• Self-State Attacks on Self-Hosted AI Agents
• Agent Data Injection Attacks are Realistic Threats to AI Agents
• OWASP GenAI: prompt injection risk and mitigations
• Google Gemini CLI advisory: update to the trust model
• NVD: CVE-2026-54316
• Black Hat: the promptware kill chain
• r/AI_Agents: prompt-injection regression testing discussion

Related guides: secure untrusted repositories and host-side consumers, build boundaries beyond permission prompts, and separate workflow approval from authorization.