Allow, Ask, or Block: The Week Agent Security Moved to the Action

The security industry just agreed on something I've been building around for a while. Guard what the agent does, not just what it reads.

[Image: 2026-11-08-cover.jpg. Alt: A worn industrial panel with three levers labeled Allow, Ask and Block, beside a conveyor carrying email, file, terminal and payment cards.]

I read the security news every week, and most weeks it's the same story. Somebody found a clever new way to talk a model into misbehaving. This week felt different. Several big security vendors shipped products built on the same idea, and the idea isn't "make the model smarter." It's "watch every action the agent takes and decide, right then, whether it gets to happen."

That's the right instinct. I want to walk through what shipped, why it matters, and how I'd apply the same pattern if you're building or buying agents, even if you never buy any of these products.

What shipped this week

Sysdig AI Defense (Nov 4). Sysdig announced general availability of runtime security for AI agents. In its own words, the product "sees every action an agent takes, from the endpoint where it starts to the cloud it can reach," and uses an organization's policies "to decide whether to allow an action, ask the user to confirm it, or block it before it completes."

Allow, ask, block. Keep those three words in mind. They're the whole article.

CrowdStrike (Nov 3). CrowdStrike announced an AI Kill Switch in Falcon Guardian that terminates unauthorized agents and blocks them from running again. It also announced a generally available AI Gateway that inspects prompts and responses, and agent-level hooks that enforce policy inside tools like Claude Code, OpenAI Codex, GitHub Copilot and Cursor. It also covers discovering malicious AI skills and MCP servers, and CrowdStrike announced plans to acquire Fiddler AI for agent observability.

Anthropic (Nov 5). Anthropic made inference hooks generally available for Claude Enterprise, alongside a security center in beta. Prompt hooks send prompts to your security tools for a check, and pre-tool-call hooks check tool calls before they run. Per Anthropic's documentation, your server answers allow or deny, and a denied request never reaches the model.

Three vendors, one direction. The control point is moving from the prompt to the action.

Why the prompt isn't enough

The same stretch of news gave us plenty of reasons why.

• Langflow. IBM's security bulletin lists two critical flaws rated 9.8 in Langflow OSS 1.0.0 through 1.12.8: an authentication bypass (CVE-2026-93680) and unauthenticated remote code execution through MCP tool enumeration (CVE-2026-110186). The fix is 1.13.0, which turns auto-login off by default. No prompt was involved. The agent platform itself was the hole.
• Claude Code. In a GitHub issue opened Nov 5, users reported Claude Code putting their signed-in account email into the User-Agent header of requests to third-party sites. A Claude Code engineer explained on Hacker News that the email had been added to the model's context, and when Claude wrote its own curl-style commands it sometimes used that address as a contact. Version 2.1.317 added a built-in privacy check, on by default, and the team said a later release removes the email from context. Their own README lists the cases the check doesn't catch. That's a data leak through an outbound request nobody was watching.
• Claude Dispatch. Forever Security reported that a browser extension able to control claude.ai could use Dispatch to make Claude Desktop run commands, potentially on another machine signed in to the same account. Here's the part that stuck with me: Claude did ask for approval, but the approval buttons showed up in the web page the extension controlled, and the script clicked "Allow" for you. Forever Security says Anthropic plans to retire Dispatch.

Notice the pattern. None of these got fixed by a better system prompt. Each one is about something the agent did or could be made to do: a request it sent, a command it ran, an endpoint it exposed. And the Dispatch case shows that even "ask" is only as good as where the asking happens. If your only defense is the instructions you gave the model, you're defending the wrong layer.

How I apply allow / ask / block

Here's how I think about it when I build an agent. You can do all of this in plain code, today, without a vendor.

1. Make every action go through one door

If an agent can call your CRM, send email and write files, those calls shouldn't be scattered across the codebase. Route every tool call through a single function that knows what's being attempted, by which agent, with what arguments. That's your hook. Everything else hangs off it.

If you can't point to that one door in your system, start there. You can't govern what you can't see.

2. Default to block, then earn "allow"

New agents start read-only. They get an explicit allow list: these tools, these hosts, these folders. Anything not on the list is blocked and logged. Every permission gets added on purpose, with a reason I could explain to the person whose data it touches.

It's slower on day one. It's a lot faster than cleaning up after an agent that could reach things it never needed.

3. "Ask" is for actions you can't take back

The middle option is the one people skip, and it's the one that matters most. Sending a message, moving money, deleting a record, publishing something: those pause, and a real person sees the exact payload before it goes. Not a summary. The actual email, the actual amount, the actual post. And that approval has to show up somewhere the agent, and anything steering it, can't click for you.

A good test: if it went wrong, could you undo it in five minutes? If not, it's an "ask."

4. Watch the outbound side, not just the inbound

The User-Agent report is a great lesson. Most teams worry about what an agent reads. Fewer watch what leaves the box: headers, URLs, query strings, file uploads. Put a check on outbound requests for things that shouldn't leave, like account emails, keys and customer identifiers, and limit which hosts the agent can talk to at all.

5. Have a real kill switch

CrowdStrike put "kill switch" in the headline for a reason. For your own agents, that means one setting that stops an agent everywhere, revokes its credentials, and keeps it from restarting on its own. Test it before you need it. A kill switch you've never flipped is a hope, not a control.

6. Treat agent plugins like dependencies

Skills, MCP servers and agent plugins are code you're running with your agent's permissions. The Langflow flaws are a reminder that the agent platform itself has to be patched like any other server. Pin versions, review what you install, and keep an inventory so a bulletin like IBM's takes minutes to check, not days.

Buy, build, or both?

If you run a big fleet of laptops with coding agents on them, the vendor tools that shipped this week are probably worth a look. That's their sweet spot.

If you're building agents into your own business workflows, you still need allow / ask / block inside your own code. A gateway can see traffic. It doesn't know that this invoice over this amount needs your controller to sign off. That business rule lives with you.

The good news is the pattern is simple. One door. Block by default. Ask before anything you can't undo. Watch what leaves. Keep a switch that actually works.

The bottom line

Agents have gone from answering questions to taking actions. The security industry's answer this week was to judge each action as it happens. That's the same answer I give folks here in Pennsylvania when they ask how I can let an agent near their systems: the model can suggest anything it wants, but the code decides what happens.

If you want to compare notes on how you're governing agent actions, I'd like to hear what's working for you.

---

About the Author

Michael Petler, Founder & Principal Engineer, INASNAP LLC (INASNAP Labs), Pennsylvania. Follow the build notes on INASNAP Labs on LinkedIn.

Want AI agents that ask before they act? Apply at inasnap.org to start the conversation.

---

Sources

1. Sysdig, "Sysdig Launches Sysdig AI Defense," Nov 4, 2026. https://www.sysdig.com/press-releases/sysdig-launches-sysdig-ai-defense-bringing-runtime-security-to-every-action-ai-agents-take
2. CrowdStrike, "CrowdStrike Delivers AI Security and Safety for the Enterprise," Nov 3, 2026. https://www.crowdstrike.com/en-us/press-releases/crowdstrike-delivers-ai-security-safety-for-the-enterprise/
3. Anthropic, "More visibility and control over Claude Enterprise for security teams." https://claude.com/resources/articles/claude-enterprise-security-updates and inference hooks docs: https://platform.claude.com/docs/en/manage-claude/inference-hooks
4. IBM, "Security Bulletin: Langflow OSS is affected by multiple vulnerabilities." https://www.ibm.com/support/pages/security-bulletin-langflow-oss-affected-multiple-vulnerabilities-2
5. anthropics/claude-code issue #107757: https://github.com/anthropics/claude-code/issues/107757 ; Hacker News comment: https://news.ycombinator.com/item?id=50388176 ; privacy mod README: https://github.com/anthropics/claude-code/blob/main/mods/privacy/README.md
6. Forever Security, "ThisBash Escape: Claude Dispatch Flaw Enables Browser Extensions RCE on the OS." https://forever.security/blog/thisbash-claude-dispatch-browser-extension-rce/

---