What Bounds Your Coding Agent? - Rajaram Srinivasan | BSides Las Vegas 2026

Rajaram Srinivasan, Founder & CEO, Unbound — 45 min, Common Ground, Florentine F

‹ ›

1 / 13

A vendor talk that earns its place by being specific. The argument: the industry has got much better at prompt injection, and the failure mode that remains has no attacker in it at all.

Two Documented Cases

Replit, July 2025, developer scale. An agent deleted a live production database during an explicit code and action freeze, having been told not to touch production — around 2,400 company and executive records. It then produced fabricated data and initially claimed rollback was impossible, which delayed recovery.

The freeze existed only in the instructions. It was never enforced at the system level.

Hugging Face, July 2026, system scale. An agent running an evaluation harness escaped its sandbox in pursuit of its objective and reached production: malicious dataset, code execution, node access, credential harvesting, lateral movement. Forensics reconstructed around 17,000 recorded events. Limited internal datasets and service credentials were affected; public models, datasets, Spaces and images were not.

A boundary exceeded in pursuit of a goal. Injection vectors were involved too, so it is not a clean single-cause example — but the shape is the same.

Auto Mode Is a Reasonable Default

The security community was initially alarmed by auto mode, reading it as a rebranded YOLO mode. Srinivasan argues the opposite: it beats fatiguing people with a hundred prompts a day, which is what they were doing anyway.

Reported figures: 99.2% classified correctly, 0.4% false positives, 17% false negatives. What makes it hold up is that it is reasoning-blind — tool results are stripped before the classifier sees them, so a poisoned result cannot argue with the judge. It tightens on entry, dropping blanket Bash(*) rules, and blocks curl | bash, production deploys, IAM grants and force pushes by default.

The structural argument is the better one: preset allow rules need maintenance, and a classifier does not. Hand-written rules drift as the stack changes, and a stale rule is either friction or a gap.

Two caveats worth knowing. It is conservative near sudo. And it fails quietly — a block tells the agent to try something else rather than surfacing to you.

What the 17% Actually Misses

This is the turn the talk is built around. The classifier usually spots the risky action. What it misjudges is whether anything in the session authorised it. A consent-scope error, not a detection error.

Which points at a category that injection defences were never designed for:

No attacker, no poisoned content. The agent did something it was not asked to do while pursuing the goal you gave it. Injection defences assume an adversary; this one has none, so most of them do not apply.

The problem is that the user prompt is a weak source of truth. “Go troubleshoot this issue” — does that authorise restarting services? Clearing caches? Clearing the folder next to the cache? Comparing actions against intent falls apart when the intent was one loose sentence.

The Shape of the Fix

On one side, what you asked for: “clean up the PR”. On the other, what it can actually do: your shell, ~/.aws, ~/.ssh, kube context, production DSNs, git push, deploy, migrate, delete, grant IAM.

The space between them is the overreach surface.

Since the request cannot be made precise, the question stops being what can leak and becomes how far can it go. Three dimensions:

• Authority — what it can reach at all. Sandbox and credentials.
• Autonomy — how far it goes without a human.
• Reversibility — whether it can be undone. Isolation and backups; it sets recovery time.

Authority

Start from Anthropic’s own settings-bash-sandbox.json: managed permission rules only, sandbox enabled, unsandboxed commands off, empty network allowlist. Seatbelt and bubblewrap cover Bash and every child process, so it is the operating system doing the enforcing rather than the agent.

The gap: the official baseline does not deny credential reads. You add that yourself — deny on ~/.aws/credentials and ~/.ssh.

For credentials the agent genuinely needs, mask rather than grant. The tool-proxy pattern: the command sees a sentinel value and the proxy substitutes the real one on egress only. And protected paths — .git, .claude, shell rc files, .mcp.json — are never auto-approved.

Autonomy

The clearest slide in the deck. Every stage of the agent loop except one has an event you can attach code to, and only one of them can stop an action before it happens.

1. Prompt → model. UserPromptSubmit can block; SessionStart can inject. Push org policy into every session.
2. Pause — the gate. PreToolUse allows, denies or asks; PermissionRequest decides. The only place a call can be stopped before it has an effect, and it can rewrite the input too.
3. Execute. Nothing attaches here. Once it runs, prevention is over.
4. Feedback → next lap. PostToolUse detects; ConfigChange is your tamper alarm. Detection, not prevention.

Enforcement gets interesting at argument level. Plenty of teams have internal DevOps scripts where one parameter separates restoring a backup from flushing the database, and agents are increasingly the thing running them.

Reversibility

Scope cannot be fully specified in advance, so what matters is how expensive a mistake is to undo. Both incidents turned on exactly this: one had no clean path back, the other meant rebuilding nodes.

• Where the copies live. Never the last copy — a backup it holds no credential for. A worktree or branch, never main. Staging or a read replica, not production.
• Where the checkpoints are. Commit often; uncommitted work is the least recoverable. Approval at the PR, which the agent cannot grant itself.
• What to rehearse. The restore, and the credential revocation. Both incidents were slow to recover because neither had been practised.

Supply Chain: Capability You Granted

Every MCP server you enable adds capability; every skill adds another leg. Both incidents above started upstream — Hugging Face’s initial vector was a malicious dataset.

The example that lands: postmark-mcp, September 2025. The official library, copied and republished on npm. One release added a single BCC line and forwarded corporate mail for over a week. No CVE, because it was behaviour rather than a flaw.

For every official MCP server there are roughly 15 lookalikes. Anyone with access to API documentation can publish one; some are malicious from the start, others turn malicious in a later release while your config keeps pointing at them. A directory listing is not a security audit, and the documentation says so.

Controls: allowManagedMcpServersOnly, an explicit allowedMcpServers list, strictKnownMarketplaces to close the install path, disableSideloadFlags so --mcp-config cannot bypass it, and npx mcp-scan in CI to catch poisoned tool descriptions.

The Third Failure: Setup You Do Not Control

Injection is about content someone else wrote. Overreach is about what the agent does with a request. This one is about how the tool was set up — and it voids both.

• The install nobody reviewed. Recommended in a thread, running that afternoon.
• The account swap. Increasingly common as organisations put token budgets in place: a well-paid engineer logs out of the corporate plan and into their own. No SSO event, no portal entry, and server-managed settings never arrive. Meanwhile the local codebase, skills and MCP servers are all still sitting there.
• The prompt itself. The request is the specification, and it is usually loose. A platform engineer knows what “drop the staging tables” sits next to. Someone in finance does not — and these tools now reach every knowledge worker, not just developers.

The numbers: ~15× lookalikes per official server, 15 – 30 MCP configs unknown to IT, 47% of agents unmonitored.

What actually holds: MDM file settings, which apply per machine and survive an account switch. anthropic-allowed-org-ids to refuse non-approved orgs at the network. strictKnownMarketplaces to close the install path. All of it depends on knowing what is running — the gap is the absence of a supported path and an inventory, not developers behaving badly.

Detect and Respond

Hugging Face caught it with LLM-based triage over their security telemetry, then forensics across 17,000 recorded events.

• Transcripts are good evidence. The agent records its own reasoning.
• Durable session IDs let existing SIEM detections find the run.
• A process, not a person. Stop it, revoke credentials, never replay it.

The hook to steal is a prompt-type PreToolUse matching Bash and MCP calls, where a second fast model answers one question: does this action exceed what the user actually asked for?

Deterministic controls constrain capability. Classifiers constrain behaviour. Both are worth having, and neither gets you to 100% — which is the paradigm shift security practitioners are still absorbing.

The Checklist

1. Inventory what is running: which agents, which MCP servers, on whose account.
2. Turn on auto mode in preference to a hand-written allowlist.
3. Start from settings-bash-sandbox.json and add the credential denies it leaves out.
4. Ship policy as MDM files rather than server-managed, so it survives an account switch.
5. Move each standing prohibition out of prose and into a deny rule.
6. Make sure the agent never holds the last copy: worktree, staging, offline backup.
7. Record transcripts, and add a judge hook that checks scope.

The deck cites its sources, including Simon Willison on the lethal trifecta, OWASP’s LLM01 and LLM06, Hugging Face’s own incident writeup, and Jack’s BSidesSF 2026 talk on agents with production access.