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.