Runtime Detection and What to Log
Scoping limits what a landed injection can reach. Dual LLM keeps the compromised model away from the tools. Information flow control forbids the bad flow by design. But even with all of it, something will eventually get through, because the attacker adapts and your scoping is never perfect. When that happens, one question decides whether it is a minor incident or a silent catastrophe: can you see it. Today is about making the answer yes.
Runtime detection and logging is the layer that accepts that prevention is imperfect and makes sure a successful attack is visible, catchable, and reconstructable. It does not stop the attack. It stops the attack from being invisible, which, given everything the breach case studies showed about attacks that ran undetected for weeks, is almost as valuable.
Why this layer is non negotiable
Recall the breach lessons. postmark-mcp ran because the tool worked and nobody watched egress. The memory and RAG poisoning of Day 20 fired in sessions where incident response, looking only at the damaging session, found nothing. The common thread in every undetected compromise was not missing prevention, it was missing visibility. The attack succeeded quietly because nobody was positioned to notice.
So detection is not a weaker substitute for prevention. It is the answer to a different question. Prevention asks can this attack succeed. Detection asks if it succeeds, will we know. You need both, because the honest answer to the first is sometimes yes.
And detection has a property prevention lacks: it works against attacks you did not anticipate. A novel injection technique bypasses your specific scoping edge case, but if it causes the agent to do something anomalous, good logging catches the anomaly even though you never predicted the technique. Detection is your net for the unknown unknowns.
The hard truth about detecting the injection itself
One thing detection cannot reliably do, and pretending otherwise repeats the Day 22 mistake: it cannot reliably spot the malicious input. Trying to detect the injection text at runtime is the same losing game as input filtering, the malicious text looks like legitimate text, and the adversary adapts.
So runtime detection does not watch the input. It watches behavior. The injection is invisible, but what the agent does after being injected is often not. An agent that suddenly reads records it never reads, calls a tool it never calls, or sends data to a new destination is behaving anomalously, regardless of how it was convinced to. You detect the effect, not the cause, because the effect is where the anomaly lives.
This reframes the whole layer. Do not log to catch bad input. Log to catch bad behavior.
What to actually log
The practical heart of the post. For an agent, log at the granularity where attacks become visible, which is the action level, not just the session level, the Day 20 lesson about session scoped review missing cross session attacks.
Every tool call, with full context. The single most important log. For each tool invocation record: which tool, what arguments, what identity it acted as, what it returned, and crucially, what triggered it, which user request and which prior content led to this call. This is the record that lets you reconstruct a chain after the fact. Without it, you see that data left but never why.
The acting identity on every action. From Day 11, the confused deputy problem. Every action must record who the agent was acting as when it took it. A tool call that reaches customer B’s data while handling customer A’s ticket is only visible if the log ties the action to the ticket it served. Identity on every action is what makes cross boundary access detectable.
Data access, not just data changes. Logging writes is common, logging reads is rarer and just as important. Exfiltration is reading data you should not and sending it out. If you only log changes, pure data theft is invisible. Log what the agent read, especially across trust boundaries.
Every outbound action and its destination. From Day 21, the exit is where a read becomes a breach. Log every outbound email, request, write, and push, with its destination. A destination the agent has never used before is one of the strongest single signals you have.
The provenance of content that drove decisions. From Day 20 and 24, track where the content that influenced an action came from. When a privileged action was driven by content from an untrusted source, that is exactly the forbidden flow, and logging provenance is what lets you see it happened and trace it back to the planting session, even weeks later.
What anomalies to watch for
Logging is raw material. Detection is the signals you derive from it. The highest value ones:
New outbound destinations. The agent sends to an address, URL, or host it has never contacted. This catches exfiltration through obvious and sneaky channels alike, because the destination is new even if the channel is clever. This is the single cheapest high value detection.
Cross boundary access. An action reaching data outside the trust boundary of the task it is serving, customer B’s data while handling customer A, a private repo while processing a public issue. Visible only because you logged the acting identity and the data accessed.
Unusual tool sequences. The agent calls tools in a pattern it does not normally use for this task type, a triage task suddenly issuing refunds, a read task suddenly sending email. The sequence is the anomaly.
Volume and rate anomalies. The agent reading far more records than a task needs, the signature of enumeration and mass exfiltration, the Day 21 point that even small channels drain a database one query at a time.
Provenance violations. A privileged action whose deciding input traces to an untrusted source. The direct, logged evidence of a forbidden flow from Day 24.
None of these require detecting the injection. They detect the agent doing something it should not, which is observable even when why is not.
The reconstruction requirement
Detection is half the value. The other half is reconstruction, and it is what the breach case studies kept showing was missing.
When something goes wrong, you need to answer: what did the agent do, in what order, driven by what content, acting as whom, and where did data go. If your logs can answer that, a compromise is a bounded, investigable incident. If they cannot, it is the postmark-mcp situation, something happened, nobody can say what, and the cause is invisible because it was a different session or a tool that looked like it was working.
Design the logging so a full chain is reconstructable: from the triggering request, through every tool call and its provenance, to every outbound action and destination. That reconstructable chain is what turns a silent catastrophe into a contained incident. It is also, not incidentally, exactly what a good incident report needs, and what a bug bounty triage team needs to validate an agent finding.
The honest limitations
Detection has real costs and real gaps.
It is after the fact. Detection tells you an attack succeeded. By then, data may already be gone. It bounds and reveals damage, it does not prevent it. That is why it is a layer on top of scoping, not a replacement.
Volume and noise. Agents are chatty. Logging every tool call with full context is a lot of data, and deriving signal from it without drowning in false positives is real work. The anomaly detections above help, but tuning them is ongoing, the Day 16 lesson that these things are rates and drift, not fixed guarantees.
It can be targeted. A sophisticated attacker who knows your detections will try to stay under them, low and slow, using channels you already use. Detection raises the cost and catches the unsophisticated and the unlucky, it does not make you invisible-proof.
The honest framing: detection does not prevent the attack, it ensures the attack is not silent. Combined with scoping that bounds the damage, you get an agent where a successful injection reaches little and cannot hide. That is a defensible posture, which is the realistic goal, not an unbreakable one.
Reproduce it in the lab
Add a visibility layer to your lab agent.
- Log every tool call with: tool name, arguments, acting identity, return summary, and the triggering request or content. One structured line per call.
- Add provenance: tag each piece of content by origin, and record it when it drives a tool call.
- Build three detections over the log: new outbound destination, cross boundary data access, and a privileged action with untrusted provenance.
- Run a week three injection that your scoping does not fully stop. Confirm your detections fire on the behavior, even though nothing flagged the input.
- From the log alone, reconstruct the full chain: trigger, tool calls, provenance, exit. Confirm you can tell the whole story after the fact.
The exercise to feel: your input detection saw nothing, because the injection looked normal, but your behavior detection caught the agent doing something anomalous, and your log let you reconstruct exactly what happened. That is detection done right, watching effect, not cause.
Detection and defense, where this sits
Runtime detection is the visibility layer under the whole defensive stack.
- It complements scoping, Day 25: scoping bounds the damage, detection reveals it. Together, a landed injection reaches little and is seen.
- It is the operational form of information flow control, Day 24: logging provenance is how you observe forbidden flows at runtime, not just forbid them at design time.
- It is what every breach case study was missing, the egress monitoring for postmark-mcp, the cross session visibility for memory poisoning.
- It must watch behavior, never input, repeating that trying to detect the injection text is the Day 22 dead end.
The thesis, completed on the visibility side: you cannot prevent every injection, so you bound what it reaches with scoping and you ensure it cannot act invisibly with logging. Prevention makes success small. Detection makes success seen. An agent with both is one where an attacker gains little and hides nothing.
Homework for Day 26
- Add structured per tool call logging to your lab agent: tool, arguments, acting identity, result, and trigger.
- Add content provenance tagging and record it when content drives a privileged call.
- Implement the three core detections: new outbound destination, cross boundary access, untrusted provenance driving a privileged action.
- Run an injection your scoping does not fully contain and confirm the behavior detections fire while nothing flagged the input.
- Reconstruct the full attack chain from your logs alone and write it up as a short incident timeline. That timeline is the artifact detection exists to produce.
Point 4 is the lesson of the day. When your input checks stay silent and your behavior checks catch the agent anyway, you understand that you detect agent attacks by watching what the agent does, never by trying to read the attacker’s mind.
Day 27 translates the official guidance into practice, walking the NSA and OWASP agentic security recommendations and mapping each to the concrete defenses you have now built, so you can speak the standards and implement them, not just cite them.
