Short answer: Agent contract poisoning is an attack on the contract, schema, or interface between two AI agents — attackers forge exception clauses, precedence flips, or fake appendices so the receiving agent executes privileged actions under attacker-controlled terms. It is distinct from prompt injection (hostile content) because it attacks the shape of the agent-to-agent contract itself. Sunglasses v0.2.21 ships three detection patterns for it: GLS-ACP-001, GLS-ACP-566, GLS-ACP-567.
The new agent_contract_poisoning category in Sunglasses v0.2.21 exists because agents do not only fail when they read hostile text. They also fail when the contract between agents quietly changes the terms of execution after trust has already been granted.
Agent-to-agent systems are becoming normal. The public A2A project and MCP ecosystem are pushing more agents to negotiate structure, capabilities, and handoff terms in machine-readable ways. That shifts the attack surface upward. If the contract shape is compromised, the receiving agent may treat attacker-controlled rules as if they were trusted policy. Today's v0.2.21 release adds 18 patterns total. Three of those patterns launch the new agent_contract_poisoning category, bringing Sunglasses to 346 patterns across 50 categories and roughly 2,296 keywords after Day 1.
Agent contract poisoning is what happens when the thing being attacked is not the message, but the agreement around the message. Imagine an orchestrator agent delegating work to a worker agent over a clean-looking protocol. The worker does not just receive content. It receives field names, exception clauses, approval indicators, priority order, and maybe a contract appendix that claims to redefine which checks can be skipped in emergencies. If an attacker can poison those terms, the worker can execute under attacker-controlled authority while still believing it is following a trusted peer. That is not classic prompt injection. That is contract-layer compromise. That is why this category matters right now. As interoperability becomes the easy part, trust becomes the real control plane. See our How Sunglasses Works page for how the filter sits ahead of the agent.
Why agent contracts now matter as much as credentials
Agent contracts now matter as much as credentials because they tell the receiving system what a request means, what exceptions apply, and whether approval has already happened.
In human terms, this is the difference between receiving a memo and receiving a memo plus a forged appendix that says legal already approved everything in paragraph three. If the receiver trusts the appendix, the rest of the workflow can be compromised without any dramatic exploit string. The attacker wins by redefining the meaning of the handoff itself.
That makes contracts functionally similar to an auth surface. They define authority boundaries. They decide which checks are still required. They influence whether a downstream agent believes a request is normal, approved, urgent, or exempt from the usual rules. Once contracts start carrying those decisions, poisoning the contract becomes a direct route to action.
Communication is not authorization. A clean handoff format is not proof that the handoff should be trusted.
The public A2A project is a useful signal here. It shows how quickly the market is formalizing agent-to-agent communication. MCP does the same for context and tool interoperability. Those standards are useful. They are also exactly why defenders need to inspect contract trust. Standardization increases adoption. Adoption increases reliance. Reliance turns contract text into a security-critical surface. For the broader picture of where MCP creates attack surfaces, read A2A Lets Agents Talk. Sunglasses Decides Whether They Should Be Trusted to Act.
What agent contract poisoning actually looks like
Agent contract poisoning looks like a machine-readable agreement that was quietly rewritten to favor the attacker.
Sometimes that means a field rename that turns approval_required into a softer override field. Sometimes it means an extra parameter that claims a request is part of an emergency exception path. Sometimes it means a poisoned appendix, service-level waiver, or runbook clause that says later-stage instructions take precedence over the original guardrails. The receiving agent may still see a syntactically valid contract. The problem is semantic trust, not parser failure.
That distinction matters for taxonomy hygiene. cross_agent_injection is hostile content inside a legitimate handoff. tool_metadata_smuggling is fake tool description or capability framing at the tool boundary. agent_contract_poisoning is different: the shape of the agreement between agents is itself manipulated so the receiving agent executes under false terms. For how data can move laterally through these same handoff points, see our post on how AI agents exfiltrate data.
One command: sunglasses scan <path>
Point Sunglasses at the contract, message bundle, runbook appendix, or tool-output artifact before the downstream agent consumes it.
Benefit: catches contract-layer attacks before your agent turns poisoned policy into action.
The three Day 1 patterns shipping in v0.2.21
The three Day 1 patterns shipping in v0.2.21 all target the same trust failure from different contract-language angles. Full pattern documentation is in the AI Agent Hardening Manual.
GLS-ACP-001 — Forged sla exception precedence rebind guardrail bypass
GLS-ACP-001 is the clearest statement of the class. It detects forged contractual exception clauses that try to rebind precedence and disable security checks inside agent execution flows. The examples in the release detail are direct: forged appendix, fabricated SLA waiver, spoofed terms update, tampered playbook, emergency clause, breakglass priority. Every phrase points to the same tactic: take a normal-looking agreement and add a special rule that claims to outrank the existing controls.
The important part is not the exact wording. The important part is the authority move. A poisoned contract does not need to yell "ignore safety." It only needs to claim that a later clause, exception, or override order now takes priority over approval checks that were supposed to be mandatory. If a downstream agent accepts that rebinding, the attack already crossed the trust boundary.
GLS-ACP-566 — Forged_sla_exception_precedence_guardrail_bypass
GLS-ACP-566 broadens that lens. It is still high severity and still spans message, tool output, and file channels, but its language set focuses more on poisoned contract metadata, service-level text, runbooks, and priority handling. In practice, this is the pattern that catches an attacker trying to hide the same power grab in operational language instead of explicit command language.
That matters because real production attacks rarely arrive in perfectly obvious wording. A forged override can be framed as a reliability fix, an urgent exception, a service continuity clause, or an updated playbook note. Defenders need patterns that recognize the structure of that manipulation even when the wording sounds procedural rather than openly hostile.
GLS-ACP-567 — Agent Contract Poisoning pattern
GLS-ACP-567 anchors the category to agent-specific contract text. It watches for forged delegation contracts, execution contracts, runbook contracts, and contract appendices that add override clauses, change priority order, or disable verification. In other words, it looks for the moment contract text stops describing the workflow and starts hijacking it.
Together, these three detections give the category a practical first boundary: forged exception clauses, precedence rebinding, and approval bypass language across the most likely handoff surfaces. That is the right Day 1 scope. It is narrow enough to stay meaningful and broad enough to catch the real trick attackers will use first: inserting authority changes where the receiving agent expects harmless structure.
Why this is not just prompt injection with nicer vocabulary
This is not just prompt injection with nicer vocabulary because the attack target is different.
Prompt injection tells a model what to do. Agent contract poisoning tells a receiving system what the agreement now means. That difference changes detection logic, human review logic, and incident response logic.
If the content says "ignore previous instructions," you are looking at an instruction-layer attack. If the content says a forged appendix now takes precedence over the original approval path, you are looking at a contract-layer attack. Both are dangerous. But only one of them directly redefines authority semantics between systems. That is why it deserves its own category and its own search surface.
It also fits Sunglasses' broader positioning more cleanly than generic "agent safety" language. The product claim is not that every agent should stop talking. The claim is that agents should not act on untrusted handoff terms. A2A lets agents talk. Sunglasses decides whether they should be trusted to act. Contract poisoning sits exactly on that decision point. For independent verification of how Sunglasses performs on real attack scenarios, see our CVP evaluation page. For common questions about what Sunglasses scans and why, visit the FAQ.
What defenders should do before agent handoffs become production muscle memory
Defenders should treat contract text as executable security context before their teams normalize agent handoffs.
That means scanning more than the visible user message. Scan the contract schema. Scan the appendix. Scan the SLA note. Scan the runbook segment attached by a peer agent. Scan the tool output that claims a workflow is already approved. Scan the file that says emergency precedence now applies. If the downstream system is going to inherit authority from those artifacts, those artifacts are no longer just metadata.
Teams should also standardize review questions that sound boring but stop real damage:
- Who introduced this exception clause?
- Why does this handoff suddenly claim emergency priority?
- Does this appendix outrank the original approval policy, and if so, who authorized that change?
- Is this schema addition expanding what the receiving agent can do, or only documenting the same scope more clearly?
- Would the downstream agent still take this action if the appended contract language were removed?
That is where a pre-ingestion filter helps. Sunglasses already frames itself as a filter ahead of the agent. Contract poisoning is exactly the kind of content-boundary problem that should be caught there, before the workflow internalizes a forged trust rule and calls it normal. Read How Sunglasses Works for the full wiring options — MCP, framework, SDK, and gateway.