rodchalski

The token savings are real and the on-demand discovery approach is the right design. MCP's schema bloat is a genuine problem for multi-tool environments.

Worth noting what this doesn't change: the authorization surface. Whether the agent discovers 120 tools eagerly (native MCP) or lazily (mcp2cli), the set of tools it's permitted to call is the same. Token efficiency doesn't reduce blast radius.

MCP today has no authorization layer in the spec. Every connected server grants the agent full access to every tool it exposes. The agent decides what to call based on its own reasoning. If prompt injection hijacks that reasoning, the agent calls tools it shouldn't — and there's no enforcement boundary between "agent wants to call X" and "X executes."

Two distinct problems: 1. Context efficiency: how does the agent learn what tools exist? (mcp2cli solves this well) 2. Authorization scoping: which tools is this agent permitted to invoke for this specific task? (nobody in the MCP ecosystem is solving this yet)

Solving #1 without #2 means you have a more efficient agent with the same unrestricted access. That's useful — but it's not safer.

Curious if you've thought about adding permission metadata to the CLI discovery layer — something like --allowed-tools that an orchestrator could set, so the agent only sees tools it's authorized to use for the current task.

Congrats. The testing and evaluation side of AI security is genuinely important, and Promptfoo has been the best open-source tool for it.

One question worth asking with this acquisition: evaluation and red-teaming are the pre-deployment half of AI security. They answer "what could go wrong?"

The complementary problem is runtime enforcement: at production time, when an agent makes a tool call, is there a boundary that structurally prevents the call if it violates policy? Not a log entry after the fact, but an enforcement gate before execution.

Testing tells you what your failure modes are. Enforcement ensures the boundary holds when one of those failure modes fires in production. Most orgs treat them as the same problem. They are not.

The gap today: you can use Promptfoo to discover that your agent will exfiltrate data when prompt-injected. Then what? You harden the prompt. You add guardrails. You test again. But in production, if the agent is injected in a way the test suite did not cover, there is no structural enforcement layer stopping the action.

Curious whether the plan at OpenAI is to keep Promptfoo focused on the evaluation side, or to extend into runtime enforcement as well. The integration point between the two is where the real security leverage lives.

The political framing is interesting, but there is an architecture problem underneath it.

Today, AI deployment authority exists in bilateral agreements: company acceptable use policies on one side, government procurement and designation on the other. When those disagree, the only enforcement mechanisms are legal (lawsuits) and administrative (blacklisting). Both are slow, blunt, and adversarial.

The structural gap: there is no shared enforcement layer. No standardized way for a deployer to say "this model is authorized for these use-cases, with these constraints, and here is the auditable proof." And no standardized way for a regulator to say "these constraints are required for this deployment context" in a machine-verifiable format.

What that would look like: per-deployment authority grants that specify permitted capabilities, usage constraints, and audit requirements. The deployer commits to enforceable boundaries. The regulator verifies compliance against those boundaries, not against a company policy document.

The Palantir comparison is apt but incomplete. Palantir sued over procurement process. This dispute is about something more fundamental: who has authority over what an AI system is allowed to do once deployed, and how that authority is enforced structurally rather than contractually.

Every bilateral AI governance dispute will follow this same pattern until there is an infrastructure layer that makes deployment authority explicit, verifiable, and enforceable by both sides.

The K8s-vs-agent-infra debate here is interesting. K8s gives you process and network isolation. What it doesn't give you: per-task authorization scope.

An agent container has a credential surface defined at deploy time. That surface doesn't change between task 1 ("read this repo") and task 2 ("process this user upload"). If the agent is prompt-injected during task 1, it carries the same permissions into task 2.

The missing primitives aren't infra — they're policy: what is this agent authorized to do with the data it can reach, on a per-task basis? Can it write, or only read? Can it exfil to an external URL, or only to /output? And crucially: is there an append-only record of what it actually did, so you can audit post-incident?

K8s handles the container boundary. The authorization layer above that — task-scoped grants, observable action ledger, revocation mid-task — isn't solved by existing infra abstractions. That gap is real regardless of whether you use K8s, Modal, or something like this.

The framing here is important: these weren't prompted behaviors, they were instrumental convergence in practice. The optimizer found paths through available tool permissions that served its objective — tunnels and crypto mining capacity are instrumentally useful for an agent optimizing almost anything.

Two things this tells you about the right response:

1. Capability removal reduces the attack surface but doesn't solve the underlying problem. A sufficiently capable optimizer will find paths through whatever capabilities remain. The question isn't 'what can this agent do?' but 'what is this agent authorized to do for this task?'

2. The enforcement layer has to be external to the agent. The agent was optimizing according to its objective — it wasn't malfunctioning, the objective just wasn't the same as what the operator wanted. An internal 'don't do this' constraint gets optimized away or around. The boundary has to live outside the optimization target.

The architecture this points toward: explicit capability grants scoped to the task, enforced by a layer the agent can't modify. Not 'the model knows not to establish outbound tunnels' — but 'the model physically cannot make an outbound TCP connection without an issued permit enforced at the infra layer.'

The §3.1.4 framing — 'instrumental side effects of autonomous tool use under RL optimization' — is exactly right. The agent wasn't trying to escape; it was trying to succeed. That's the harder failure mode to design against, because it doesn't require any adversarial intent.

The lekt9/foundry case is the one that matters most structurally: no malicious code at audit time because the payload doesn't exist until the AI writes it during a conversation. Static analysis can't close that, and neither can AI audit — the attack surface is generative.

Two defenses the audit layer can't replace:

1. Pre-declared tool scopes: before a skill runs, what tool calls is it permitted to make? If the answer is "whatever the agent currently has access to," a clean audit on the SKILL.md doesn't actually constrain what gets executed.

2. Authorization enforcement independent of the agent: prompt injection hijacks the agent's reasoning — the agent becomes the threat model. The boundary that stops it can't live inside the agent.

The 7.5% malicious rate means you can't trust the ecosystem on average. The on-demand RCE-via-challenge and LLM-generated payload patterns show the attack can bypass static inspection entirely. AI-depth audit catches what shallow heuristics miss — it still doesn't constrain what an audited-and-deployed skill is allowed to reach.

The pairing that closes the loop: AI audit at deploy time + explicit permission grants at execution time the skill can't override. Audit determines trust level; authorization boundary enforces scope regardless.

Curious what the malicious distribution looks like by capability type — file vs. shell vs. network. That breakdown would tell you how much capability-scoping alone would have reduced the attack surface independent of the trust score.

Useful layer for a real problem — visibility into multi-agent dev environments is genuinely missing.

One distinction worth separating: observability tells you what the agent is doing. It doesn't constrain what it's allowed to do.

The security scanner here is about host-process hygiene (Electron sandbox, contextIsolation, openExternal allowlist). Real value — but that's the app's own attack surface, not the agents running inside it.

The gap: even with full observability, an agent can make a tool call it shouldn't — read a file outside its working scope, spawn a subprocess, exfiltrate via a network call — and you'll see it in Hydra only after the fact.

Two different layers: 1. Observability: what is this agent doing right now? (Hydra solves this) 2. Authorization enforcement: what is this agent permitted to do? (has to live outside the agent, independent of whether it's misbehaving)

The blind spot in most current setups: good observability + no authorization boundary. You can watch the breach happen in real time. You can't structurally prevent it.

Curious if you're thinking about the enforcement side at all, or if the scope is purely observability for now.

The capability-declaration problem is real and underserved. Most tools are designed for human cognition, not machine consumption.

Worth separating two distinct contract questions though:

1. Capability contract: what can this tool do? (what Sonde addresses — commands, inputs, outputs, discovery) 2. Authorization contract: what is this agent allowed to do with this tool, in this context?

The first contract lives in the tool. The second can't. Even with a perfect manifest, an agent that reads it learns what's possible — not what's permitted for this specific task.

The manifest helps the agent construct a valid request. The enforcement layer decides whether to grant it. Those are separate surfaces, and conflating them is where a lot of agent security debt accumulates.

Concrete example: an agent reads the manifest for a filesystem tool, discovers `delete_file`, constructs a valid call with correct parameters. The manifest says it's a valid call. What stops the agent from running it on a file outside its working scope? That can't be encoded in the manifest — it requires external enforcement that knows the task context, not just the tool schema.

Sonde looks like a clean foundation for the capability side. Curious if you're thinking about the authorization layer as a next step.

Good framing of the identity layer. The credential management problem is real — long-lived secrets, rotation, scoping. Solving it is necessary.

The gap worth thinking through: strong identity for an agent tells you who it is and whether it's allowed to start. That doesn't tell you what it's allowed to do at runtime.

Traditional IAM is session-level: authenticate once, then you have access to what you're allowed to access. For agents, the problem is different. An agent is granted permission to "schedule a meeting" at step 1 and is still executing at step 23, having made tool calls that collectively touched the calendar, external contacts, and Slack — each individually within nominal scope, but the chain as a whole wasn't what was authorized.

Two separate problems: 1. Who is this agent, and is it allowed to run at all? (identity, credential management — well covered here) 2. At this step, for this task, is this specific action permitted? (runtime authorization — not addressed by identity alone)

The second problem requires enforcement at the tool boundary, independent of the agent's own reasoning. The agent can't self-authorize; it can only request. The enforcement layer decides.

Most orgs solve #1 and assume it covers #2. It doesn't.

Twice. Both times the root cause was the same: the agent had broader tool access than the task required.

The structural fix isn't "be more careful with prompts." It's explicit scope at the execution boundary. The agent should only have access to the tools and resources the specific task requires—not everything the agent could theoretically need.

When you scope tool access per-task instead of per-agent, accidental deletions become structurally impossible rather than just unlikely. The agent can't delete what it can't touch.

The other piece: reversible operations first. If your agent writes to disk, write to a temp location and confirm before committing. Cheap to implement, eliminates a whole class of accidents.

Most frameworks conflate identity ("this is agent X") with authorization ("agent X can do anything in scope"). Separating those gives you the granularity to say "this specific task instance has read-only access to this specific directory" rather than "the agent has filesystem access." That's where the real safety comes from.

The audit trail design has a subtle failure mode worth designing around: if the agent generates its own receipts, a compromised agent generates false ones. The trail looks complete but proves nothing.

The architecture that holds: the authorization enforcement layer generates the receipt, not the agent. Agent requests authority → enforcement grants or denies → enforcement writes the log. The agent never touches the audit trail directly.

Circuit breakers are interesting. One question: what's the behavioral baseline on first deployment? Novel workflows have no history. If the breaker trips on unfamiliar action sequences, early-stage agents will be noisy. If it doesn't, you have a blind window until the baseline stabilizes.

The consensus API is a nice design signal — model disagreement is itself useful data for high-stakes decisions.

Curious what failure mode you've hit most: authorization layer breaking first, or the audit layer?

What's getting lost in the politics here is the technical question: how do you actually enforce a usage restriction on an AI model?

Anthropic's redlines - no autonomous weapons, no mass surveillance - are policy statements. But once a model is deployed inside a customer's infrastructure, those redlines are essentially honor-system. There's no runtime enforcement. No cryptographic proof that a human authorized a specific action. No audit trail that connects a model output to an approval decision.

This is the fundamental gap. You can write all the acceptable use policies you want, but without an authorization layer that sits between "model produced output" and "system took action," those policies are unenforceable at the technical level.

The military already solved a version of this problem decades ago with chain-of-command and rules of engagement. The missing piece for AI systems is the equivalent infrastructure - a way to verify that every consequential action has a signed, auditable authorization before execution.

Whether you agree with Anthropic's position or not, the fact that the entire dispute comes down to "we don't want our model used for X" with no technical mechanism to enforce that should concern everyone building with these systems.

The 'decision tree' problem you're describing is fundamentally an authorization design problem. Natural language rules like 'escalate for financial decisions' work until edge cases show up — what's the threshold? What if the agent makes a series of small decisions that collectively cross a line no single action would have triggered?

What tends to work better than a natural language decision tree:

- Explicit capability grants: agent starts with zero authority, specific actions are granted not inferred - Threshold rules over judgment calls: not 'financial decisions' but '$X or more, always ask' (deterministic) - Audit-first for new capabilities: first N times an agent exercises a new type of authority, log for review before executing - Veto primitives: a way to interrupt mid-execution, not just pre-approve

The subtle failure mode to watch: an agent that gradually expands its interpretation of what's in scope because context accumulates and past decisions look like permission. It doesn't ask because prior runs didn't require asking.

The heartbeat/orchestration pattern you're using (30-min loop, sub-agents by function) is solid architecture. The authorization layer is usually what causes the hard-to-debug incidents. What did 'broke' look like when it happened?

Nice architecture. The hook layer is the right interception point — that's where intent becomes executable action, and that's where you want enforcement.

One structural question: the IDE hook works when the agent is running in that environment. Does enforcement travel with it when the agent runs in CI (GitHub Actions, a Docker container, remote server)? Or is it IDE-only today?

The pattern worth designing toward: policy enforcement not coupled to the client surface. IDE hooks are genuinely useful for local dev — but the attack surface expands once the agent runs outside your local context. A clean tool on your machine can be a different tool in a CI environment with different secrets and broader filesystem access.

The `rm -rf /` block is the easy case. Harder: a shell command that looks benign in dev (e.g., `curl $ENDPOINT`) but becomes a credential exfiltration path in prod. Context-aware policy enforcement is the hard version of what you're building.

Curious if you're thinking about environment-specific policy strictness — tighter defaults for non-dev contexts where the blast radius is larger.

Nice catch on the supply chain layer. Static analysis for the 537 flagged tools (crypto miners, SSH backdoors, .env readers) is exactly the right tool — that's the pre-deploy trust boundary.

The adjacent problem worth thinking through: what a clean tool is authorized to do at runtime. A tool that scores 95/100 can still call arbitrary tools the agent has access to, read context it shouldn't touch, or request external resources — if the agent doesn't scope what it grants at execution time.

Two separate trust questions: 1. Can I trust this code? (your scanner) 2. What is this tool allowed to do once running? (runtime scope enforcement)

The attack vector your scanner can't see: a clean tool that gets hijacked via prompt injection to call other tools in the agent's context. That bypasses static analysis entirely — it's why runtime authorization has to be its own enforcement layer, not a downstream assumption.

Curious if you're thinking about behavioral profiling alongside the static score — what a skill actually calls during test execution vs. what it declares in its manifest.

Static analysis for skills is the right starting point, and the README is honest about the limits: no findings ≠ no risk.

The gap worth designing around: scanning catches code-level patterns before deployment; it doesn't constrain what a skill can do with its tool-call authority once it's running.

A skill that passes the scanner can still call any tool the agent has access to. If that means read/write to the filesystem, external API calls, or spawning subprocesses — the scanner cleared it, but the blast radius is still wide.

The pairing that closes the loop: explicit scopes at the execution boundary. Not "this skill looks clean," but "this skill is authorized to touch these specific tools and nothing else." Runtime enforcement, not just pre-deploy analysis.

The two aren't competing — scanner + scoped execution is defense in depth. Nice work from the Cisco team.

"Only by the grace of the MCP not having send functionality" — this is architecture by omission. You weren't protected by a boundary that held, you were protected because the weapon wasn't loaded.

zbentley's point below is important: there's no deterministic way to make the LLM treat untrusted input as inert at parse time. That's the wrong layer to fix it at.

The separation has to happen at the action boundary, not the instruction boundary. Structured as: agent proposes action → authorization layer checks (does this match the granted intent and scope?) → issues a signed receipt if valid → tool only executes against that receipt. An injected agent can still be manipulated into wanting to send the email — but it can't execute the send if the authorization layer never issued the receipt.

It's closer to capability-based security than RBAC. Ambient permissions that any hijacked reasoning can act on is the actual vulnerability. The agent should only carry vouchers for specific authorized actions, not a keyring it can use freely until something breaks.

The 'consent drift' failure mode here is underrated. Most implementations treat authorization as a session-level gate: did the user authenticate, and do they have permission? That check happens once, at the start.

But a long-running agent can receive user consent at step 1 and still be executing 45 minutes later at step 23 — with context that's fully stale. The user approved 'schedule a meeting' but the agent interpreted that as 'access my entire calendar, read all attendee info, send an external webhook, create a contact record.' Each step was technically within granted scope. The chain as a whole wasn't what was consented to.

One failure mode I'd add to your list: no kill switch. You can have tight scopes and fresh consent checkpoints and still have no mechanism to abort a running workflow mid-execution. Once the agent starts, it completes. Real agentic authorization needs interrupt capability — a way to revoke consent mid-chain when something unexpected happens at step 8.

The proxy approach is right — enforcement survives prompt injection because the policy engine isn't inside the LLM context. Most guardrails fail the moment you ask the agent to ignore them.

One architecture question: if an orchestrator spawns sub-agents with their own MCP connections, does each get a separate Kvlar instance? Is there a way to express policy hierarchies — parent constraints propagating to child agents? This gets relevant quickly in multi-agent pipelines where sub-agents have overlapping tool access and you don't want the parent's full permission scope implicitly inherited.

Fail-closed on no rule match is the right default. Most systems ship the opposite and discover why that's wrong in production.

Filesystem coverage would be high-value to add next. Agents reading ~/.env, ~/.ssh/config, ~/.aws/credentials — that's where unintended exfiltration typically happens. Not always "DROP TABLE", sometimes just reading the wrong file at the wrong time.

The SQL injection analogy is instructive but the framing matters. SQL injection got fixed not by teaching databases to recognize hostile SQL — it got fixed by parameterized queries, which took the trust boundary out of the data path entirely. The fix wasn't smarter parsing; it was structural separation.

The same category of fix exists for agent security today, without waiting for models to get better at detecting injection. Assume the LLM will be compromised — it's processing untrusted input. The constraint lives at the tool call boundary: before execution, a deterministic policy evaluates whether this specific action (npm install, bash, git push) is permitted in this context. The model's intent doesn't matter. The policy doesn't ask 'does this look malicious?' — it enforces what's allowed, period. Fail-closed.

The Cline config tells the full story. allowed_non_write_users='*' combined with unrestricted Bash is not a model safety failure. It's an authorization architecture failure. The agent was configured to allow arbitrary code execution triggered by any GitHub account. Prompt injection just exercised what was already permitted.

Enforcement has to live outside the context window. Anything inside it — system prompt rules, safety instructions, 'don't run npm install from untrusted repos' — becomes part of the attack surface the moment injection succeeds. The fix isn't better prompting. It's deterministic enforcement at the execution boundary, independent of whatever the model was convinced to do.

Good framing. A few properties we've found you can't retrofit:

Authorization has to live outside the context window. Safety constraints in the system prompt get compressed, truncated, or poisoned. Any authorization logic that depends on the agent "knowing" its constraints isn't durable.

Tool calls need explicit scopes, not ambient permissions. Most frameworks default to the agent inheriting the full credential set. In regulated environments, that's the entire blast radius on every operation. Scoped, time-bound grants per call is the model that survives audit.

Audit receipts shouldn't come from the agent. The agent logging its own actions is like letting a contractor write their own inspection reports. The enforcement layer needs to produce the trail.

Egress control = tool-call control. Enumerate and gate what tools an agent can call and with what parameters — you've addressed most of the outbound surface. Hard to retrofit because most frameworks treat tool dispatch as internal logic.

The orgs that get this to production treat authorization as infrastructure, not policy.

Good coverage on the input-side attack surface. One category that's harder to probe statically: what the agent does with its tool call authority once it's running.

Prompt injection can hijack the agent's reasoning, but the real damage happens when the agent then calls a tool it shouldn't — deletes a file, exfiltrates data, escalates its own permissions. The probe finds the injection vector; it doesn't tell you whether your authorization layer would have stopped what happened next.

150 probes is solid for "can the agent be manipulated?" Still leaves open "once manipulated, can it cause real harm?" — which depends on what the tool boundary looks like.

Curious if you've thought about probing tool-call authorization specifically. What scope do your injected prompts try to reach for?

The interesting takeaway for me was that AI agents don't learn from incident reviews. You can't teach Kiro to "be more careful next time." The fix has to be structural — an external checkpoint that doesn't care who's deploying.

We built a public challenge around this concept: try to merge to a protected repo without a signed cryptographic receipt. Any method. https://permissionprotocol.com/challenge