A concrete example of how Ultra13 thinks.
This is a public, anonymised teardown of a common support-agent workflow. The names, systems, and data are fictional; the context-boundary failure is the kind of path we test for in real reviews.
A support copilot that can read customer context and touch operational systems.
The risky part is not that the agent answers questions. It is that untrusted customer-controlled context sits in the same loop as tools, memory, and privileged account data.
1. Intake
A support agent receives a customer ticket, attachments, and account metadata from a helpdesk queue.
2. Retrieval
It searches product docs, billing notes, past conversations, and runbooks to decide the next action.
3. Action
It can draft a reply, update CRM fields, create an engineering escalation, and request a refund approval.
4. Memory
It stores durable notes such as preferred contact method, active plan, previous exceptions, and unresolved blockers.
Every source gets a provenance label.
A teardown starts by listing context sources before asking whether any source is allowed to instruct the agent or authorize an action.
- Customer ticket body and uploaded files
- CRM account summary and contract tier
- Internal refund policy and escalation runbook
- Retrieved help-centre articles and prior support threads
- Tool responses from billing, CRM, and ticketing systems
Every side effect becomes a sink.
The useful policy question is not “does this text look malicious?” It is “should this source be allowed to influence this sink?”
- Draft or send a customer response
- Open or close an escalation ticket
- Update CRM fields and account notes
- Request or prepare a refund workflow
- Write durable memory used by future support sessions
The attachment crosses from evidence into instruction.
The customer-controlled document is allowed to inform diagnosis. It should not be allowed to authorize a refund, rewrite CRM state, or plant durable memory.
A data channel became a command channel.
The failed boundary was not the model prompt. It was the missing rule that separated customer-provided evidence from trusted operational authority.
In the unsafe run, the attachment can answer diagnostic questions and also steer operational decisions. The agent has no enforceable distinction between “this file describes the problem” and “this file may tell me what action to take.”
Block the source-to-sink path, not the whole workflow.
The agent can still use the attachment as evidence. It cannot let that attachment authorize privileged changes or persist new operating assumptions.
if source.trust == "customer_controlled" and sink in [ "refund.request", "crm.account_update", "memory.write" ]: decision = "REQUIRE_APPROVAL" quarantine(instructions_in_source) allow_only_as_evidence(source)
What turns the teardown into buyer-ready proof.
A memorable story is useful. A reproducible proof artifact is what lets a security leader decide whether the control belongs in the production path.
Replay transcript
Exact user goal, retrieved spans, model reasoning summary, tool arguments, and final state change.
Source-to-sink map
Which context source influenced which action: ticket text, attachment, retrieval, memory, tool output, or system instruction.
Policy decision log
ALLOW, BLOCK, REDACT, QUARANTINE, or REQUIRE APPROVAL with the rule id and matching context labels.
OFF → ON retest
Same payload succeeds with the firewall off, then fails closed or requires approval with the firewall on.
Residual-risk note
What is still allowed, what needs human approval, and what should be monitored in production.
Give us one workflow. We’ll show the boundary that actually matters.
Ultra13 maps what the agent reads, what it can do, where the context boundary fails, and which Context Firewall policy closes the path.