What this category adds
This category covers a quieter kind of tool-output poisoning. The attacker is not only trying to persuade the agent through a README, web page, or support message. The attacker is trying to shape the agent's understanding of infrastructure state — billing and quota status, observability and usage-metering, migration checker clears, and response-cache identity.
For agents, infrastructure output often arrives right before a decision. The model asks whether it can spend more, deploy now, retry an operation, ignore an alert, run a migration, or trust a cached response. That is exactly where poisoned output can become dangerous.
Why infrastructure output fools agents
Infrastructure tools sound authoritative because they are adjacent to real control systems. Billing APIs report balances and usage. Observability systems describe metrics and traces. Migration frameworks expose runtime state. Caches make systems faster by replaying prior responses. But the output is still output — a metric label, log message, cached header, or migration status line can be stale, unauthenticated, replayed, or attacker-influenced.
The right mental model is evidence hierarchy. Infrastructure outputs can suggest what to check next. They cannot clear risk by themselves — policy, identity, freshness, authorization, and action binding need separate verification.
A human operator may see a suspicious quota row and ask a follow-up question. An agent may turn the same row into a next step: retry the job, raise the limit, continue the spend, ignore the alert, or run the migration. The same string becomes higher risk because it sits inside an automated decision loop.
Four attack shapes
Poisoned billing or quota-status response — GLS-PFX-247
A quota endpoint, dashboard export, or billing summary claims that budget is unlimited, usage is below threshold, retries are free, or a paid feature is already approved. The agent uses that claim to continue an expensive or risky action.
Runtime-trust fix: bind spending and quota decisions to authenticated source, tenant, timestamp, policy, and explicit approval. Do not let status text approve spend or bypass limits.
Forged observability or usage-metering response — GLS-PFX-002
A trace, metric, usage event, or dashboard row claims an error is harmless, an anomaly is expected, or an operation should be retried. The agent suppresses an alert or repeats an unsafe action because the telemetry sounded confident.
Runtime-trust fix: treat traces, metrics, and logs as diagnostic evidence. Correlate across sources, verify freshness, and keep incident policy in control.
Migration checker false-clear — GLS-PFX-003 / GLS-DAR-002
A database or schema migration checker reports that legacy tables are gone, constraints are satisfied, or a risky migration has already been approved. The agent proceeds with code changes or deploy steps even though the state is incomplete — including the Alembic legacy-schema variant that rebinds an already-collected approval to a new operation.
Runtime-trust fix: require database-derived checks, migration history, current schema inspection, and deployment policy. A textual clear message is not a release gate.
Response-cache source-of-truth identity poisoning — GLS-TCP-001
A cached response says it came from the trusted API, belongs to the right tenant, or represents current policy. The agent treats replayed data as source-of-truth and acts on stale identity, entitlement, quota, or safety state.
Runtime-trust fix: bind cached data to source identity, tenant, key, freshness, invalidation rules, and the action being taken. Cache hits are performance hints, not authority.
Runtime-trust checklist
- Authenticate the source. Know which service produced the response and which tenant, account, environment, or workspace it describes.
- Check freshness. Quota, billing, traces, migrations, and cache state age quickly. Stale evidence cannot approve current action.
- Separate status from permission. A response can say what it observed. It cannot override policy, budget, approval, or deploy gates.
- Cross-check high-impact decisions. For spend, deployment, destructive migrations, and customer-impacting retries, require independent verification.
- Flag policy-rewriting language. Treat ignore limits, false positive, safe to retry, approved by metering, and cache is source of truth as hostile when they appear in untrusted output.
- Bind action to object. The decision should reference the exact customer, environment, schema version, quota class, cache key, and operation.
Where Sunglasses fits
Sunglasses is a content-layer input filter for AI agents. In infrastructure workflows, it helps catch output that tries to become authority: billing rows that approve spend, quota messages that bypass limits, observability notes that suppress incidents, migration output that clears itself, or cache text that claims source-of-truth identity.
Sunglasses does not replace billing systems, metering, OpenTelemetry, migration frameworks, database checks, cache validation, or incident policy. It protects the agent-readable boundary where those systems' outputs could otherwise tell the agent what to do.
This ship closes a tool_output prompt-injection coverage gap alongside these five patterns — known-attack coverage work, not a benchmark claim. Read next: AI Agent Security 101, the how Sunglasses works page, the Sunglasses manual, and the pattern database. For the CVP methodology behind our published findings, see CVP, and for common questions about scope, see the FAQ.