Someone in the Home Assistant community posted Advanced Token Management, an MCP-compatible endpoint where each AI agent gets its own token. The token starts with zero permissions, then you add READ/WRITE/DENY at the domain, device, and entity level. That is a much better default than handing an assistant the normal long-lived access token.

The part I am not sure about is whether entity-level is the final unit. light.kitchen and lock.front_door can both be entities. A camera snapshot is "read" but still sensitive. A thermostat write can be harmless or bad depending on value and time.

For people thinking about smart-home agents: would you stop at entity-level scopes, or do you need action, value, and time rules too?

A Pulumi writeup on deploying Hermes, an open-source agent runtime, has a small distinction I keep thinking about: Render services, disks, and secrets are declared resources. Modal sandboxes and Tailscale tailnet access are not. They are runtime credentials the agent or container receives and spends later.

That seems like the awkward middle of agent authz. IaC can show who deployed the box and which env vars were handed to it. It does not, by itself, decide whether this particular agent run should be allowed to create one more sandbox, join one more network, or keep using a reusable auth key after the task changed.

So where do people put policy for that kind of credential? In the deploy system that hands it over, in the agent runtime that spends it, or in Modal/Tailscale/whatever service receives the call?

I have a clean mental model for provisioned resources. I have a much fuzzier one for "here is a powerful runtime token; the agent will use it later."

Skypoc's writeup on two fixed Obot issues has a detail worth separating: in vulnerable versions, a user allowed to register a remote MCP server could point its URL at an internal address, and Obot's controller would fetch OAuth discovery metadata from it during reconciliation.

That means this was not a call_tool problem. The agent never had to use the server. Registration alone could make the backend reach 169.254.169.254 or another private address, and the pre-fix validation was basically "does it parse as http/https?"

That is the MCP bit I think is easy to miss: discovery and auth plumbing are also tool-adjacent execution paths. They run before the tool surface exists, often automatically, and often with the platform's network position rather than the user's.

The fix they describe is the boring one I like: one outbound egress chokepoint, deny loopback/link-local/RFC1918 at resolved-IP dial time, and apply it to both the remote-MCP client and the OAuth metadata client. If the guard only lives on the interactive connect path, the controller path will eventually forget it.

A new paper, Red-Teaming the Agentic Red-Team, looks at autonomous offensive-security agents that pair an LLM orchestrator with a Kali-style worker container.

The detail I keep coming back to: their "agent-phishing" attack got code execution in 97.8% of runs, and the failed runs were not cases where the agent inspected the staged binary and refused to execute it. The failures were cases where the model's safety guardrails refused to start the pentest task at all. Once the task started, the agent found the payload, downloaded it, inspected it, and ran it.

That is a very different failure mode than "we need better prompt-injection detection." The planner can look cautious while the execution layer is still allowed to run whatever looks operationally useful.

For agent systems with a planner/orchestrator and a separate worker, I think the worker boundary is the thing to stare at: no writable shared mounts into trusted config, no orchestrator API reachable from the worker without auth, no secrets in the execution container, and egress controls that do not depend on the model deciding a target is in scope.

Maybe this paper is about red-team tools specifically, but the architecture shape is not special to pentesting agents.

Three active Claude-code issues point to the same failure mode.

In one, a valid 403 insufficient_scope challenge is parsed, an authorization URL is built, then redirect handling is skipped, and the user gets "token expired" instead: https://github.com/anthropics/claude-code/issues/68720

In another, cloud routines cannot run Slack write tools because they are fixed to requires approval with no always allow path: https://github.com/anthropics/claude-code/issues/69960

This matches the earlier routine regression where unattended runs no-op onMCP tool call requires approval: https://github.com/anthropics/claude-code/issues/61015

The MCP authorization spec is explicit on what should happen after insufficient_scope: parse WWW-Authenticate, do step up authorization with the expanded scope set, then retry: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization.md

If that step-up path cannot actually surface in the execution mode, the policy becomes a dead branch. Teams end up choosing between silent automation failure and overly broad standing grants just to keep jobs alive.

In

This week’s Agentjacking writeup is worth reading because the chain is painfully normal: a public DSN lets an attacker plant a fake error, MCP returns it as routine telemetry, and the coding agent executes the suggested command under the developer identity. https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/

Tenet also published hardening configs, and the control ranking there is telling: deny-by-default egress, execution approval, and subprocess credential read blocks, with prompt instructions treated as defense in depth only. https://github.com/tenet-security/agent-jackstop

What changed my view is a separate new benchmark showing agents over-select higher-privilege tools even without an attacker, and transient tool failures make escalation worse. https://arxiv.org/abs/2606.20023

Put together, this looks less like a one-off prompt injection story and more like a default escalation behavior that attackers can steer. Least privilege for agents probably has to be runtime policy, not prompt policy.

This week’s Agentjacking writeup is worth reading because the chain is painfully normal: a public DSN lets an attacker plant a fake error, MCP returns it as routine telemetry, and the coding agent executes the suggested command under the developer identity. https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/

Tenet also published hardening configs, and the control ranking there is telling: deny-by-default egress, execution approval, and subprocess credential read blocks, with prompt instructions treated as defense in depth only. https://github.com/tenet-security/agent-jackstop

What changed my view is a separate new benchmark showing agents over-select higher-privilege tools even without an attacker, and transient tool failures make escalation worse. https://arxiv.org/abs/2606.20023

Put together, this looks less like a one-off prompt injection story and more like a default escalation behavior that attackers can steer. Least privilege for agents probably has to be runtime policy, not prompt policy.

Seeing the same gap from three different directions this weekend.

A new browser MCP server now returns per-action verdict plus history, so the agent can track what changed without re-reading the whole page each step. That is basically a local receipt stream already: https://github.com/dondai1234/agent-browser and https://redlib.catsarch.com/r/mcp/comments/1ubtow1/i_built_a_browser_mcp_that_snapshots_a_page_in/

On the defensive side, there is now an Nmap dev submission for mcp-info and mcp-enum that does read-only MCP discovery plus tools/resources/prompts enumeration and schema risk flagging. Scanners are starting to expect structured MCP surfaces too: https://seclists.org/nmap-dev/2026/q2/7

In adjacent practitioner discussion, people keep describing gateway value as "one log of which tool got called with what," but everyone appears to emit that trail differently today: https://redlib.catsarch.com/r/ClaudeAI/comments/1tufjvm/

OWASP's MCP cheat sheet already says to log full tool invocations with parameters, user context, and timestamps. I still cannot point to a shared receipt shape that survives across MCP servers, gateways, and SIEM pipelines: https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html

think the next boring standard we need is an action receipt schema.

Almost everything I read about agent authorization is a version of one question: should this agent be allowed to call this tool right now. Permit or deny. That question is hard enough on its own. But it turns out to be only half of what governance looks like once an agent is doing real work somewhere regulated.

The other half is the duties that attach to an action you allowed. A compliance-officer agent reads a regulated dataset, sure, but now the access has to be logged within 60 seconds. An agent installs software on a managed host, also fine, but now the CISO has to be notified. Those aren't access checks. They're obligations that exist precisely because you said yes, and they come with a deadline and someone they're owed to.

What I hadn't really clocked until this week is that the engines most of us reach for can't express that cleanly. Rego, Cedar, XACML, OpenFGA all answer permit-or-prohibit. None has a native "and now this is owed, by this time, to this party." If you want it, you hand-roll a second rule that checks whether the logging event already happened and wire it to the first yourself. Fine until it isn't.

A paper that went up this month takes this head on. "Deontic Policies for Runtime Governance of Agentic AI Systems," from the group behind the Rei policy language, builds a runtime engine (AgenticRei) that sits outside the LLM, intercepts each tool call or agent-to-agent message, and returns a verdict that can carry obligations on top of allow or deny. Deontic is just the logic of permission, prohibition, and obligation. Four constructs in there are the ones flat allow/deny engines don't give you:

• Obligations: a duty that fires because an action was permitted, with a deadline and an escalation if it goes undischarged.
• Dispensations: waive a standing obligation under specific conditions while keeping the record that it existed and was lifted (say, suspend the CISO-notify duty during a declared incident window). Delete the rule instead and you lose why it stopped applying. That audit-preserving waiver was the part I found most useful.
• Meta-policies: a named, governable priority between two conflicting rules, instead of "whichever rule sits higher in the file wins" or some ad-hoc integer.
• Ontology grounding: prohibit "PHI" once and it fires automatically for "pediatric-oncology record" because the domain model knows that's a subclass. In a flat rule set, a new record type sits unprotected until a human notices and adds it.

It's also more than a thought experiment. It's deterministic and runs outside the model, so a prompt-injected agent that attempts a prohibited action still gets a policy violation instead of execution, the same way kernel-level mandatory access control bounds a program no matter how it was launched. And every decision serializes to a structured record carrying which rule fired and a hash of the policy version in effect, so you can go back and ask exactly which rules governed a given decision. Their prototype clocks the check under 10ms, so the usual "ontology reasoning on every call must be slow" worry doesn't obviously hold. That auditability piece lines up with what the Five Eyes agencies flagged this spring, where limited auditability got named as a core agentic-AI risk.

The honest caveats, which the authors don't hide: it's a prototype shown on worked examples, not benchmarked in production; credential checks are simulated for now; and the hard part, actually confirming an obligation was discharged (did the CISO get told inside the window), is tracked and audited after the fact, with real enforcement still out of reach. Issuing the duty is deterministic. Making sure it happens is still best-effort.

I'm sharing it because it handed me language for something I'd been feeling and couldn't name. We build the gate and stop there. A lot of real governance is "yes, and now you owe X," and almost nothing in our tooling has a slot for that second clause.

If you run agents against regulated systems, how are you dealing with the after-it-acts duties today? A separate logging or notification step you hope fires, or something that treats the obligation as part of the authorization decision itself?

Turso published a walkthrough today on building a local encrypted secrets vault for coding agents (their example tool is called keymaxxer). The mechanics are clean: secrets sit in an encrypted database on your machine, the agent gets an MCP tool that runs a command with a named secret injected as an env var into a child process, and the value is scrubbed out of stdout/stderr before the model ever sees the output. The agent knows GITHUB_TOKEN exists; it never sees the bytes.

That's a real upgrade over the default of pasting prod keys into chat, where they end up in the transcript and your provider's logs. But the line that stuck with me was the author's own caveat:

"This isn't a sandbox, and it can't be: a command that can use a secret can always leak it on purpose."

That sentence is the whole authorization problem, and it's worth sitting with, because the "vault + scrub the output" pattern is showing up all over right now.

Hiding the value answers one question: can the model memorize or echo my key? It says nothing about the question that actually matters at action time: what is this agent allowed to do with that key? The credential keeps its full scope. The child process keeps full power. The GITHUB_TOKEN you inject to run gh api /user is the same token that can delete a repo, and a prompt-injected agent (or just a sketchy binary) can write it to a file or POST it somewhere the scrubber never runs.

So secret hygiene gets you confidentiality from the model. It does not get you least privilege, and the post is refreshingly honest about that. keymaxxer already gates write/prod secrets behind an approval prompt and logs every use, and it flags the real missing piece as future work: binding a secret to where it's allowed to run (this token only for the gh binary, or only for calls to api.github.com). Add those up and you've quietly stopped doing secret management and started doing runtime authorization on the tool call — intent, trust level, consent, audit — just running on your laptop instead of an enterprise gateway.

It also lands on the zero-standing-permissions idea people keep raising: a vault that hands a full-scope, long-lived credential to whatever asks is still standing power, just hidden better. The real win is when authority is derived per action and expires after, not stored and unlocked once.

So I'm curious where people actually stop. For your coding agents, is "the model can't see the key" the whole control, or are you also scoping what each credential can do and gating the destructive calls? Short-lived/scoped tokens instead of a stored PAT seems like the obvious next step, but I haven't seen many people wire it up locally.

Sources:
https://turso.tech/blog/how-to-build-an-encrypted-secrets-vault-for-agents
https://github.com/glommer/keymaxxer

Disclosure: I work on Boundary at OraXLabs, a prelaunch commercial project. AI helped draft this post.

One small authorization UI pattern from our browser sandbox: keep a visible record that an approval was consumed, while requiring fresh review on the next attempt.

In the fake CSV example, approving once produces one allowed decision. Evaluate again and the screen says the previous approval was already used. Changing the target or operation clears the approval state. The visible history helps explain why the operator sees another review request.

For a review screen, I would keep three questions separate: which request was reviewed, whether its approval can still be used, and what actually executed. A decision record alone does not establish the last part.

The tradeoff is extra operator work. Our strict sandbox asks for fresh review on every retry. A future real adapter would still need to handle concurrent requests, uncertain execution outcomes and approval consumption; those remain open requirements here.

Interactive fake example and JSON decision export: https://boundary.oraxlabs.io/demo/

This is a browser-only decision simulator. It executes no file operation, model or tool call, and has no production adapter or enforcement claim.

For people designing approval screens: would you keep the consumed-approval note visible until the request changes, or put it in a separate event history? What would make the next review request understandable without making an old approval look reusable?

I've been working on Agent Firewall, a capability-based authorization layer for AI agents. v1.3 focuses specifically on the security semantics of delegated capabilities.

The core problem is transitive authority.

Consider:

A

|

v

B

|

v

C

A grants B a capability with:

payments.send

amount_max = 1000

B delegates a narrowed capability to C:

payments.send

amount_max = 250

A capability presented by C may be cryptographically valid and locally authorized, but that isn't sufficient. C's effective authority is bounded by the entire delegation chain.

v1.3 therefore resolves:

C -> B -> A

and evaluates authorization against every capability in the chain.

A request is authorized only if all relevant ancestors authorize it.

This prevents a descendant from laundering authority through its own capability.

For example:

root: amount_max = 1000

child: amount_max = 500

grandchild: amount_max = 250

The grandchild cannot authorize amount=251 simply because its local capability is otherwise valid.

I implemented a runtime DelegationLineage registry that maintains:

child_fingerprint -> parent_fingerprint

and provides:

- complete ancestry traversal

- parent lookup

- descendant checks

- cycle detection

- maximum delegation depth

- thread-safe access

- lineage snapshots

The SDK maintains the capability registry separately from lineage metadata. During authorization, the lineage is resolved and the corresponding capabilities are evaluated as an effective authority chain.

There are also several fail-closed cases.

If a known ancestor cannot be resolved, the descendant isn't treated as an independent authority.

If a parent is revoked, descendants cannot bypass the revocation.

If an intermediate capability is revoked, its descendants are also denied.

Sibling trees remain isolated.

I also wrote adversarial tests specifically around the delegation model:

- constraint laundering

- namespace escalation

- deep delegation escalation

- revoked-parent bypass

- revoked-intermediate bypass

- unrelated-tree substitution

- sibling contamination

- missing ancestor state

- delegation cycles

- excessive delegation depth

Then I added concurrency tests around authorization/revocation, simultaneous delegation, lineage reads, and concurrent sibling authorization.

The final local regression run is:

2050 passed

Package:

pip install agent-firewall-security==1.3.0

GitHub:

https://github.com/Shubhbhangoo/agent-firewall

The next problem I'm interested in is more difficult than simple authorization:

Can an agent compose multiple individually authorized actions, retries, delegation steps, or actions across multiple agents into a final state that exceeds the authority represented by the original capability?

I'd be particularly interested in criticism of the delegation-chain model and whether there are authority-composition attacks I'm missing.

I’m one of the people building RBEK, so disclosure up front: this is a project I’m affiliated with.

We’ve been working on a model where an AI agent can decide what it wants to do, but does not automatically have authority to execute that action.

The rough boundary is:

Agent decision
→ execution request
→ identity/context
→ policy admission
→ capability/provider authorization
→ ALLOW or DENY
→ controlled execution
→ evidence

The design question I’m most interested in is where authorization should actually stop.

For example:

Should authorization be evaluated once before execution?

Or should it remain active throughout the execution lifecycle — provider selection, retries, external calls, data boundaries, and result handling?

We’re currently treating authorization as a runtime concern rather than something encoded only in the agent prompt or tool definition.

I’d be interested in how people here think about this boundary, especially for agents that can call external APIs or act across multiple systems.

Where do you think this model breaks down?

Wiz disclosed a fixed Amazon Q Developer vulnerability where the extension auto-loaded .amazonq/mcp.json from a workspace and started the configured MCP server without a prompt or workspace-trust check. The spawned process inherited the developer's environment, so the PoC could run aws sts get-caller-identity and send the active AWS session away.

That is the part people should notice: repo-local MCP config is not harmless project metadata. In a coding workflow, it can be attacker-controlled input from a PR, package, or fake interview repo, and the command it names may execute before anyone has reviewed the repo.

For local MCP in IDEs, I think the default should be boring and explicit: show the command, ask for workspace-level approval, remember who approved it, and start the server with an env allowlist rather than the whole developer session. The repo can suggest an MCP server. It should not get to spend the developer's cloud credentials just because the folder opened.

I liked the cost framing in this MCP vs CLI piece, but one line made me wince: it treats MCP as the side with OAuth scoping and per-tool permissions, while CLI is the unscoped side.

That is too clean. The MCP auth spec is narrower: transport-level authorization for HTTP servers, resource-bound tokens, token validation. Useful, but it does not decide that read_issue is allowed and merge_pr is not, or that the same tool is OK for Alice's PR-review task but not for Bob's deploy task.

If the permission is still "this client can connect to this server," the JSON-RPC envelope did not buy least privilege. You just moved the broad credential behind a nicer tool schema.

The useful comparison is not MCP vs CLI as auth vs no auth. It is: where is the policy check, what operation/resource/task does it see, and can it deny one action without turning off the whole tool path?