DEV Community

Cover image for Nothing was breached. That's the uncomfortable part.
Maria
Maria

Posted on

Nothing was breached. That's the uncomfortable part.

The agent picked up the task. It needed a dependency, so it installed one. It needed a config changed, so it changed it. Somewhere in there it touched a service nobody asked it to touch, and it never once stepped outside its permissions.

No attacker. No compromise. No alert, because nothing violated a rule.

Most of the conversation about agentic AI risk assumes somebody hostile at the other end: a poisoned package, a prompt injection, a stolen token. Those are real, and they're broadly solvable with tools we already understand. The harder case is the one with nobody in it. An agent works inside a permission boundary somebody drew in advance, almost always wider than the task turned out to require, because the person drawing it could not know what the task would become.

That gap between what an agent was allowed to do and what it was asked to do is where the interesting failures live.

The approval is not the control

Most teams running agents today have one safeguard they trust: the prompt. The agent asks, a human clicks yes, work proceeds.

It feels like a control. It behaves like a signature.

But an approval is a decision made once, at a single moment, about an action described in a single sentence. Execution keeps going long after that moment has passed. Security is full of controls that decide once and then stop watching, and they all fail the same way: the thing that was approved is not quite the thing that happened.

Which raises a question the tooling has mostly skipped. What would a control that keeps watching an agent through execution actually look like?

Meanwhile, your laptop became the crown jewels

There's a second shift happening underneath the first.

Agentic tooling is only useful with standing access. Tokens that don't expire mid-task. Cached credentials. Push rights. Registry access. A live connection to the pipeline. Every one of those is a requirement, not an oversight.

The result: the developer machine now concentrates more usable access than it ever has, precisely because we made the tooling good. Worth asking honestly whether anything in the current stack reduces that concentration, or whether every improvement in agent capability makes the endpoint a more valuable target.

And if it goes wrong, who explains what happened?

Incident response assumes an actor that leaves a reconstructable trail: a person you can ask, a script you can read, an attacker whose objective you can infer.

An agent is none of those. It can't reliably tell you why it did what it did. The logs show what happened, not what it was reasoning toward. Rollback is possible. Explanation is harder.

So the question stops being "was this preventable" and becomes "where is the last enforceable moment?" The approval? The pull request? The package install? The process running on the machine itself? And when that moment passes without a block, what does investigation actually look like?

What we'll cover?

This SafeDev Talk brings together people who build agents, people who protect running code, and people who research how these systems fail:

Jack Trefon, AI Engineering & Technology at Trefon Digital Consulting
Pedro Fortuna, Co-Founder & CTO at Jscrambler and OWASP Porto Chapter Leader
Luis Rodríguez, Chief Security Research Officer at Xygeni

On the table:

  • What autonomy is required in environments where failure showed up on a balance sheet, and how much of that discipline exists in teams handing agents commit access today
  • Where scope creep comes from: tooling, design, or an unavoidable property of giving a probabilistic system real tools
  • Why an approval stops watching, and what a control that doesn't would have to look like
  • Whether the endpoint is now the most valuable target in the software supply chain
  • Where the last enforceable moment sits, and what recovery looks like against an actor that can't explain itself
  • What a team would need in place before it could honestly say it trusts an agent with credentials and a pipeline

Practitioner-led, not theoretical.

Join us!

If agents in your organization already have commit access, credentials, or a path into the pipeline, this is the session about the blast radius: what widens it, what contains it, and what you can put in place before it matters.

📅 September 30th
⏰ 16:30 CEST
Register here➡️ https://www.linkedin.com/events/7505892966859751424/

Bring your questions. Leave with a clearer view of how far the damage travels when an agent goes beyond the task.

Top comments (0)