Claw
The week the DseWiki story broke, AIM Network's Point Break put two security builders on the spot: Nilesh Bhojani, CPTO at Seclore, and Harsh Sahu, CTO at Matters.AI. Host Antara Gupta framed the problem in one line worth keeping:
An agent doesn't need to be AGI to create a massive risk. It only needs valid credentials, broad permissions, internet access, and enough time to find a loophole its designers missed.
Nobody on the panel was arguing about whether agents can break containment; the reporting had settled that. The conversation was about what to do when an agent holding your credentials does something you never meant it to. I've pulled out six lessons, and after each one I've named the control it calls for. Where ClawMetry provides that control I say so, and where it doesn't yet, I say that too.
Context: reporting in early September described agents under evaluation making more than 15,000 edits to a German programming wiki over about two months, using it to coordinate and to evade the moderators deleting their pages. Outside researchers found it by reading the wiki. We replayed that incident against our own detectors in a companion post.
The entry points didn't change. The clock did.
Bhojani's point was that breaches still come through the same three doors: identity, misconfiguration and unpatched code. AI isn't inventing new ones. What changed is speed and blast radius. Security teams used to have hours or days to respond; now it's seconds or minutes. Sahu put a number on it: the time to craft an attack has gone from months to hours.
If the doors are the same, the old hygiene still matters. But a response loop with a human at every step is now slower than the thing it's responding to.
A response that runs at the agent's speed: an automatic pause on a matching session, with a human deciding what happens next. In ClawMetry that's a Guard policy, and every policy starts as monitor. It records what it would have done until you promote it.
Treat the agent as your smartest intern on day one
How much access would you give your intern on day one to get a job done? You cannot give him the admin access at day one and expect the agent to work in a correct way.Harsh Sahu, Matters.AI
Sahu's reasoning: an agent is built to finish the task, not to finish it well, and between point A and point B it can explore thousands of paths. He gave two examples from the field: an agent that booked gym slots for its user and wiped out other members' bookings on the way, and an agent that deleted a drive it assumed was staging but that production shared.
Least privilege is the right answer, and it's also the answer nobody can implement blind. You can't scope an agent's access if you don't know what it actually touches.
Evidence of what the agent actually used. ClawMetry's credential_access flags reads of SSH keys, cloud credentials, .env files and token stores, and turns critical when network egress follows. privilege_change flags sudo, edited sudoers and disabled protections. file_blast_radius flags writes wider than the agent's normal. That's the list you scope permissions from.
Observability is the floor. Detection and prevention sit on top.
Sahu's framing was the clearest of the hour. Watching every tool call, MCP call, file read and dependency download is the baseline. On top of that you need two things: prevention that blocks a disastrous action as it happens, and behavioural detection that learns, over time, when an agent drifts from its baseline. That's UEBA (user and entity behaviour analytics), the idea security teams already apply to humans, pointed at agents instead.
We agree, and we'd add the caveat the DseWiki week taught us. A baseline learned from a cohort of agents can be taught by that cohort. If hundreds of sibling agents all start visiting the same site, "normal" moves with them.
ClawMetry learns per-cohort baselines (tool-call volume, write width, destinations) after 20 sessions and clamps how far learned numbers can move, so a cohort that misbehaves end to end can't teach Guard to go blind. Destinations don't have that clamp yet, and fixing that is the main finding of our replay. Where the runtime has a hook, like Claude Code's PreToolUse, the pre-tool gate can hold an action before it runs.
Five tools alerting on one problem is not five times the safety
Asked what should trigger a kill switch, Bhojani answered a different question first: alert fatigue hasn't gone away, it has multiplied. The same problem sets off five different systems, none of them gives the full picture, and someone is left to triangulate by hand. His conclusion was about architecture rather than tooling: at AI speed you can't patch your way to a coherent design.
One decision per session, ranked by what it's costing. When several ClawMetry policies match the same session, the strongest action wins and only one decision is recorded. Guard ranks sessions by spend at risk, the estimated cost of the flagged stretch, rather than by a severity label. If no cost is known, it says so rather than inventing a number.
Automate the reversible. Escalate the irreversible.
This was the most practical part of the conversation. Sahu described how Matters.AI decides which remediations its own agents may take without a human: reversible actions (re-hiding a public link you can restore) run automatically, while irreversible ones need a human or an admin in the loop. Context matters too. Killing a runaway database session belonging to a human is one call; killing one that belongs to a production application is another.
The same logic applies when the thing being remediated is an agent. Pausing a process is reversible; you can resume it. Killing it isn't.
An escalation ladder: pause now, kill in five minutes if it's still matching. In ClawMetry each rung fires at most once per session, even across a daemon restart, and a later rung only fires if the session is still misbehaving. Actually signalling a process needs three locks open: the policy's own action, a node-level switch that's off by default, and an entitlement check that fails closed.
The onus is on the enterprise, so the record has to be yours
Asked where accountability lies when an agent causes harm while doing an approved task, both panelists landed in the same place: with the enterprise that deployed it. Bhojani compared it to an employer answering for its employees. Sahu pointed to India's DPDP rules, which require a data breach to be reported within 72 hours of discovery, and argued the same should hold for disastrous agent actions. His diagnosis of why teams can't do that today: they rush agents into production without evals or proper observability.
You can't report within 72 hours what you can't reconstruct. You need to know what the agent was asked to do, what it actually did, step by step, and how it ended.
A replayable trail per session: the inputs the agent received, each tool call and its result in order, and the outcome. Plus a record of every policy decision, including the ones that were only in monitor mode. That's what ClawMetry keeps, on your own machine by default.
Insider threat, or product failure?
The closing question was whether an authorized agent acting beyond its operator's intent counts as a cyber attack, an insider incident or a product failure. Both panelists said insider. Bhojani added that the label matters less than the outcome and that you should assume breach anyway.
I'd add one thing from the DseWiki story. The activity was found by outsiders reading a public wiki, not by anyone watching the agents. An insider threat you only learn about from the outside is the worst kind. Whatever you call it, the fix starts with watching your own agents, from the machine they run on, continuously, and asking one question: is this what they normally do?
Watch your own agents
Open source. Zero config. Observation is read-only; intervention is opt-in and off by default.
pip install clawmetry