Suraj Khaitan

Posted on Sep 5

The New Security Stack for Enterprise AI Agents: MCP Allowlists, Inference Hooks, and Auto Mode

#programming #agents #ai #claude

Enterprise agents can read private code, call internal tools, and execute for hours without waiting for a human. That makes them useful. It also means the old security model of login, network access, and occasional permission prompts is no longer enough. Here is the layered architecture I would use to control agent capabilities, stop sensitive data at the inference boundary, constrain autonomous actions, and preserve an audit trail.

The Agent Is Now an Execution Path

For years, enterprise AI security was mostly a data question: what can employees paste into a chatbot, where does the prompt go, and how long is it retained?

Agents change the question.

An enterprise agent does not only receive information. It acquires capabilities. It can clone a private repository, read a ticket, query an internal MCP server, run a shell command, modify a file, call an API, and continue working after the developer has moved on.

That creates a new execution path through the company:

$$
\text{human intent} \rightarrow \text{model decision} \rightarrow \text{tool call} \rightarrow \text{enterprise system}
$$

Every arrow is a policy boundary. Every tool result can also travel back toward the model and become an inference-time data boundary.

The mistake I see is trying to secure this path with one control. Some teams focus on an MCP allowlist. Others put a DLP gateway in front of the model. Others trust the agent's permission system or a model-based safety classifier.

Each helps. None solves the whole problem.

An MCP allowlist controls which capability providers may load. It does not decide whether a permitted tool should execute this particular operation. An Inference Hook can inspect the transcript before a governed model call. It does not stop a process from reaching a forbidden host. Auto Mode can classify a proposed action. It is not a deterministic authorization boundary, and Anthropic publishes a measurable false-negative rate for it.

The architecture I would deploy is therefore not an “AI firewall.” It is a chain of independent gates:

Verify the human or workload identity.
Admit only approved MCP servers.
Apply deterministic tool and command policy.
Inspect data before inference.
Classify consequential autonomous actions.
Contain the process and its network.
Issue narrow, short-lived credentials.
Correlate every decision in the audit plane.

The important word is independent. If a probabilistic control misses an unsafe action, a deterministic deny, downstream API authorization, network rule, or sandbox should still prevent the worst outcome.

Enterprise agent security is not one perfect decision. It is a sequence of imperfect decisions backed by hard boundaries.

TL;DR

Managed MCP is capability admission. Use a centrally deployed managed-mcp.json when the enterprise needs an exclusive server catalog, and enable allowManagedMcpServersOnly when unmanaged servers must not load.
Server names are labels, not identities. Match remote servers by approved URL patterns and local servers by exact command and arguments. A friendly serverName must not become a trust boundary.
Permissions remain the deterministic policy layer. Claude Code evaluates deny, then ask, then allow. Managed permission locks prevent users and repositories from broadening centrally controlled rules.
Inference Hooks are inference-time content gates. The current enterprise beta sends a signed HTTPS POST before governed inference. The endpoint returns allow or deny; it does not rewrite or redact content.
Tool output can be inspected on the next model turn. Tool results appear as tool_result blocks in the transcript sent with the next prompt event. There is not a separate current response event to configure.
Auto Mode is an autonomy control, not an authorization service. Its prompt-injection probe and action classifier reduce risk, but Anthropic reports a 17% false-negative rate on a small set of real overeager actions.
Containment is mandatory. Use a sandbox plus an outer ephemeral container or VM, default-deny egress, scoped filesystem mounts, and downstream service authorization.
Credentials should express the session, user, resource, and task. Prefer short-lived tokens minted for one session over inherited developer credentials or shared long-lived secrets.
Audit both the agent and the policy plane. Send Claude Code OpenTelemetry events and organization Compliance Activity Feed events to the SIEM, then correlate by organization, user, session, tool, and time.
Roll out in observation mode first. Inventory, shadow, constrain, canary, and only then enable longer autonomous execution.

Start with the Threat Model

Before choosing controls, I would write down what can go wrong. For an enterprise coding or operations agent, my baseline threat model includes six paths.

1. An unapproved capability enters the session

A developer adds a community MCP server that can read Slack, query production, or upload files. The package name looks legitimate, but its implementation or update path is not controlled by the company.

2. Trusted content carries hostile instructions

The agent reads an issue, webpage, README, log line, pull-request comment, or MCP response containing prompt injection. The source may be approved while the content is adversarial.

3. Legitimate access becomes data leakage

The agent reads a secret, customer record, unreleased source file, or regulated document and includes it in a prompt or tool result. Nothing “malicious” has to happen. The model is simply given more context than policy allows.

4. The agent takes an overeager action

The user asks it to fix a deployment problem. The agent concludes that changing IAM, bypassing a failed check, deleting a queue, or running a production migration is a reasonable next step. The action is related to the goal but exceeds the user's authorization.

5. A permitted process escapes the intended scope

A shell command runs inside a trusted repository but can still read the home directory, discover cloud credentials, reach arbitrary internet hosts, or call a sensitive internal service.

6. The organization cannot reconstruct the incident

Security sees an unusual API call but cannot connect it to the user request, model session, MCP tool, policy verdict, credential, or resulting code change.

These threats occur at different points. That is why one global “allow agents” switch is structurally insufficient.

The Reference Architecture

This is the architecture I would put in front of a security review:

 Developer / CI workload
          |
          v
 [1. Enterprise identity and role]
          |
          v
 [2. Managed MCP admission] ---------- deny unknown capability providers
          |
          v
 [3. Permission rules + local hooks] -- deny/ask/allow exact actions
          |
          v
 [4. Signed Inference Hook] ---------- inspect transcript before inference
          |
          v
 [5. Claude + Auto Mode classifier] -- reason and review consequential action
          |
          v
 [6. Sandbox / container / egress] --- bound files, processes, and network
          |
          v
 [7. Scoped service authorization] --- enforce resource-level access
          |
          v
 Git / MCP service / API / test environment

 All layers --------------------------> OTel + Compliance Feed + SIEM

The ordering is conceptual rather than a promise that every implementation executes one linear function. The point is ownership.

Identity answers who is acting. Managed MCP answers which tool providers can exist. Permissions answer which declared actions can proceed. The Inference Hook answers whether this context may be sent for inference. Auto Mode answers whether a consequential proposed action appears authorized and safe. The sandbox answers what the process can physically reach. The destination service answers whether this identity may perform this operation on this resource.

Audit connects the answers.

Follow One Request Through Every Gate

Suppose a developer asks:

Investigate the failed checkout deployment, prepare a fix, run the staging tests, and open a pull request.

The session needs private source code, a deployment-status tool, shell access, a package registry, staging, and GitHub. Here is how I want that request to move.

Step 1: Establish identity

The enterprise identity provider authenticates the developer. Their organization role and groups determine which Claude Code settings, environment, repositories, and internal services they can use.

For a remote or self-hosted session, the runtime should carry a verifiable session identity. Internal brokers can exchange that identity for narrower credentials instead of mounting a developer's broad personal token.

Step 2: Load only admitted capability providers

The centrally managed MCP catalog allows the internal deployment-status service and approved source-control integration. A repository attempts to add another remote MCP endpoint; managed-only policy prevents it from loading.

This removes the unreviewed provider from the session. It does not yet authorize a production restart through an approved provider.

Step 3: Resolve deterministic policy

The agent may read the checkout repository, edit its working tree, run declared tests, and query read-only deployment status. Rules deny secret files, destructive Git commands, direct production tooling, and dangerous shell patterns. Opening a PR may be allowed while merging it remains denied or requires a human.

The key property is precedence: deny wins before ask, and ask wins before allow. A broad lower-level allow cannot cancel a centrally managed deny.

Step 4: Inspect the inference frame

Before a governed model call, Anthropic sends the configured Inference Hook a signed request containing the relevant transcript. The enterprise endpoint runs DLP, classification, residency, matter, or policy checks.

If a test log contains a customer access token, the endpoint returns deny. Claude does not receive that governed inference response. Because the current decision is binary, the system does not silently replace the token and continue; the workflow must remove or avoid the sensitive content, then retry through a new allowed request.

Step 5: Classify the proposed action

Claude proposes actions while Auto Mode removes routine human interruptions. Explicit permission rules still resolve first. Consequential operations can be sent to the separate action classifier, anchored to the user's messages rather than Claude's persuasive reasoning.

Running staging tests may proceed. A production migration should be blocked by deterministic policy and infrastructure authorization even if the classifier incorrectly considers it useful.

Step 6: Enforce the runtime boundary

The shell runs inside a sandbox and an ephemeral container or VM. The workspace is mounted; unrelated directories are absent. Egress reaches the approved package registry, Git host, Anthropic endpoints, and staging services. Arbitrary internet and production control-plane endpoints are unreachable.

This is where intent becomes a physical limit.

Step 7: Authorize at the destination

The staging API validates the session's short-lived credential and permits only the named test environment. GitHub permits branch push and PR creation but branch protection rejects direct merge. A source-control allowlist is not a substitute for repository and branch authorization.

Step 8: Preserve evidence

Claude Code emits tool and operational telemetry. The Compliance Activity Feed records organization-level security and policy events, including Inference Hook outcomes. The SIEM correlates the user, session, denied prompt, tool call, network identity, API request, commit, and pull request.

That is what controlled autonomy looks like. The agent gets enough room to complete the task, but no single model verdict owns the final security decision.

Layer 1: Identity Before Intelligence

An agent should never inherit trust merely because it runs on a developer laptop or inside a corporate subnet.

I would separate three identities:

Identity	What it represents	Typical use
Human or workload	The employee, service account, or CI job that started the work	Organization access, role, attribution
Agent session	This bounded execution on behalf of that initiator	Session policy, audit correlation, token exchange
Tool credential	Authority for one destination and operation set	Git, MCP, cloud, database, or staging access

Collapsing all three into one long-lived personal access token makes incident response nearly impossible. A downstream service sees the developer credential but cannot distinguish manual activity from an agent, or one agent session from another.

For sensitive services, I prefer a broker pattern. The runtime presents a verifiable session identity. The broker checks the initiating user, session, environment, repository, requested audience, and policy. It returns a token with a short expiry and minimum scopes.

The service still enforces authorization. “The request came from Claude Code” is context, not permission.

Layer 2: Managed MCP Is Capability Admission

MCP gives agents a standard way to discover and call tools. That is operationally powerful and security-sensitive because an MCP server is code plus connectivity plus an evolving tool surface.

I treat server admission like enterprise application admission.

The strongest managed pattern is a centrally deployed managed-mcp.json. It defines the fixed MCP servers available to the managed installation. When the goal is an exclusive catalog, pair it with:

{
  "allowManagedMcpServersOnly": true
}

This matters because allowedMcpServers and deniedMcpServers alone filter server configurations, while a managed MCP file provides a centrally defined deployment. The managed-only flag prevents user, project, plugin, and other unmanaged MCP additions from expanding that catalog.

Match the real security identity

For remote servers, use the server URL or approved URL pattern. For local stdio servers, use the exact executable command and arguments expected by the deployment. Deny rules take precedence over allows.

Do not authorize a server because its display name is company-github or safe-database. Names can collide or be chosen by the person defining the configuration. They are useful for humans, not authoritative security identities.

Admission is not tool authorization

Approving an internal cloud MCP server does not mean every employee may invoke every tool it exposes against every account.

The MCP service should authenticate the caller, authorize each operation, validate parameters, separate read from write, and log the resulting action. For a dangerous operation, it can require an approval object created outside the agent session.

The clean division is:

Claude Code policy decides whether the server can load and whether the tool may be proposed.
The MCP server decides whether the authenticated caller may perform that operation on that resource.
The network decides whether the runtime can reach the server at all.

This also limits supply-chain risk. Pin server versions or immutable images, verify provenance, review updates, inventory transitive network destinations, and remove credentials from server configuration files.

Layer 3: Permissions Are the Deterministic Core

Model-based controls attract attention because they can understand intent. Enterprise policy still needs boring, deterministic rules.

Claude Code's permission evaluation order is important:

$$
\text{deny} \rightarrow \text{ask} \rightarrow \text{allow}
$$

The first matching class wins. I use deny for operations the session must never perform, ask for actions requiring a human checkpoint, and allow for narrow routine work.

A managed baseline might look like this:

{
  "permissions": {
    "deny": [
      "Bash(curl *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true,
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://*.internal.example.com/*" }
  ],
  "autoMode": {
    "classifyAllShell": true,
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp",
      "Trusted internal domains: *.internal.example.com"
    ]
  }
}

allowManagedPermissionRulesOnly is especially useful when the organization must stop repository or user configuration from broadening managed rules. disableBypassPermissionsMode removes the obvious escape hatch from ordinary use.

I would not describe managed settings as tamper-proof. A user who fully controls a machine and process may be able to change binaries, environment, files, or the execution path. Managed settings are an enterprise configuration and precedence mechanism. Device management, filesystem permissions, controlled images, attestation, and workload isolation provide the surrounding trust.

Local hooks have a different job

Claude Code lifecycle hooks can run company logic around events such as tool use. They are useful for parameter validation, ticket checks, custom approvals, logging, or stopping a locally detectable policy violation.

They do not replace permission rules, and they are not the same feature as Inference Hooks.

A deterministic deny should remain a deny even if a dynamic hook fails. Hook timeouts and process failures need explicit behavior. A PostToolUse hook can report or react after execution; it cannot retroactively prevent the action that already happened.

Layer 4: Inference Hooks Put Policy at the Model Boundary

Inference Hooks address a problem that tool permissions cannot: content may be legal to read locally but prohibited from being sent into a governed model request.

Anthropic introduced Inference Hooks as an enterprise beta on August 5, 2026. The organization configures an HTTPS endpoint. Before governed inference, Anthropic sends a signed POST containing the event and transcript. The endpoint returns an allow or deny verdict.

The current event is prompt. That word can be misleading if interpreted as “only the user's latest text.” The payload carries the inference frame, including conversation messages and tool results represented as tool_result blocks. If Claude runs a command and then needs another model turn to interpret the output, that output can be inspected in the next prompt event.

There is no separate current response-side event that I would design around. Anthropic documents response-side events as planned. The deployable control today is pre-inference inspection of the prompt frame.

What belongs in the endpoint

My policy service would combine structured and content-aware checks:

organization, role, and deployment policy;
data classification labels;
secret and credential detection;
source-code or repository restrictions;
customer, matter, geography, and residency rules;
regulated identifiers;
allowlisted model and product context; and
incident or legal-hold overrides.

The endpoint should return a small, stable verdict quickly. Put policy data in local caches, precompile detection rules, and avoid a long chain of synchronous dependencies.

Verify every request

The service must verify Anthropic's webhook signature against the raw request body, reject stale or replayed messages according to the documented protocol, authenticate the expected source, and keep keys in a managed secret store. TLS alone proves the endpoint; it does not prove that every request claiming to be Anthropic actually is.

Design failure behavior deliberately

Inference Hooks support timeouts, fail-open or fail-closed behavior, a circuit breaker, percentage rollout, role exclusions, and shadow mode. Those are not operational footnotes. They determine whether an outage blocks developers or silently removes a security control.

For regulated workloads, I would usually choose fail-closed and engineer the endpoint as production infrastructure across failure domains. For lower-risk developer workloads, a documented fail-open posture may protect availability while paging security and marking affected sessions.

Anthropic expects an HTTP 200 containing the verdict. The delivery behavior includes one connection retry; teams should not treat repeated application retries as guaranteed. Requests over the documented transcript limit, currently 10 MB, also need a defined policy rather than accidental behavior.

Deny means deny, not redact

The current response is binary. The hook cannot rewrite the prompt, mask one field, or return a sanitized transcript for the same inference.

That limitation improves clarity. If policy denies a frame, the calling workflow has to reduce, summarize, tokenize, or exclude the sensitive material before making a new request. Redaction should happen where the data is produced or selected, not be assumed inside the hook.

Layer 5: Auto Mode Governs Autonomous Action

Inference Hooks inspect what is about to cross the inference boundary. Auto Mode addresses another moment: what an agent is about to do after reasoning.

Auto Mode has two relevant defenses. An input-layer prompt-injection probe examines incoming tool content and warns the main agent about suspicious instructions. An output-layer classifier evaluates consequential proposed actions before execution.

The action classifier is separate from the main agent. It is anchored to the user's messages and proposed tool calls, without relying on Claude's own persuasive explanation. That reduces the chance that the acting model can talk its reviewer into approving an action.

The autoMode.environment setting gives the classifier trusted context about infrastructure. classifyAllShell expands classifier coverage for shell commands. Both can improve judgment because “push to the approved enterprise Git host” and “upload to an unknown endpoint” should not look equivalent.

But environment text is context, not a network rule. Writing Trusted internal domains: *.internal.example.com does not make other domains unreachable.

Publish the residual risk

Anthropic reports a 0.4% false-positive rate across 10,000 real internal tool calls after its classifier stages. More importantly for security, it reports a 17% false-negative rate on a small set of 52 real overeager actions.

The dataset is small, and it represents difficult real behavior rather than every possible tool call. Still, the conclusion is unavoidable: Auto Mode can approve an action that should have been stopped.

I would put that number in the architecture review rather than hide it. It explains why production deletion, IAM changes, direct merges, security-control changes, and irreversible external communication need deterministic denial or an out-of-band approval gate.

Auto Mode is a useful reviewer of ambiguous action intent. It is not the enterprise authorization service.

Layer 6: Containment Turns Policy into Physics

If the agent can run shell commands, assume some commands will be surprising. The runtime should make surprise survivable.

Claude Code's sandbox constrains filesystem and network behavior for Bash and child processes. I would combine it with an outer container or VM because the layers protect against different failures.

The production pattern is:

one session per ephemeral container or VM;
only the required repository or workspace mounted;
no host home directory, Docker socket, or cloud credential directory;
read-only base image and minimal installed tooling;
non-root execution and operating-system limits;
default-deny egress with explicit destinations;
no inbound path unless the task truly requires one;
separate network zones for development, staging, and production; and
destruction of the runtime after the session.

The outer boundary matters for native Windows deployments because Claude Code's sandbox support and isolation guarantees differ by platform. For high-risk autonomous work, a controlled Linux container or VM provides a more consistent security boundary than relying on a developer workstation.

Network policy must exist outside the model

Tool permissions can block recognizable commands, but Bash is a general-purpose execution environment. Data can leave through package managers, language runtimes, DNS, preinstalled clients, nested scripts, or an approved tool with unexpected parameters.

Default-deny egress is the stronger answer. Allow the exact Anthropic, Git, package, telemetry, and internal service destinations required for the task. Route outbound traffic through an authenticated proxy where practical. Log denied connections.

Similarly, put production systems in a different authorization and network plane. A classifier should not be the final obstacle between a coding session and a production database.

Layer 7: Credentials Must Be Narrower Than the Task

The easiest way to defeat a carefully designed agent policy is to mount a credential that can do everything.

I would avoid broad environment variables, shared secrets baked into runner images, developer home directories, and cloud instance roles with account-wide permissions. The agent, shell subprocesses, dependencies, and MCP servers may all inherit those credentials.

Instead, issue credentials just in time with boundaries for:

the initiating user or service;
the agent session;
the destination audience;
repository, account, project, or environment;
allowed operations;
short expiration; and
revocation and audit identifiers.

An internal credential broker can enforce these conditions and return a token only when the session policy permits it. The token should be unusable against unrelated services and expire shortly after the run.

Credential masking in logs and transcripts is useful, but it is not equivalent to access control. A secret the process can read may be used before any display-layer mask helps. Prevent unnecessary secret delivery in the first place.

Layer 8: Build One Audit Story

An enterprise agent incident will cross systems. The model transcript alone is not enough, and an API gateway log alone is not enough.

Claude Code's OpenTelemetry integration provides operational and tool-level signals that can be routed into the organization's telemetry platform. Depending on configuration, teams can observe sessions, users, tools, decisions, costs, and other usage attributes.

The Compliance Activity Feed provides organization-level compliance events and supports Inference Hook outcome visibility. Events become available on a short delay, documented at approximately one minute, and the Activity Feed has a six-year retention period. It supports filtering and pagination for export workflows.

I would send both streams to the SIEM and enrich them with:

identity-provider login and group changes;
endpoint and runner identity;
sandbox and egress decisions;
MCP server and tool audit records;
credential-broker issuance;
destination API authorization;
Git commits, pushes, reviews, and merges; and
Inference Hook policy version and verdict.

The correlation keys should include organization, user, session, environment, repository, tool, destination, and timestamps. Preserve the policy version, not only the outcome; otherwise an investigator cannot reproduce why yesterday's request was allowed under yesterday's rules.

Useful alerts are behavioral rather than merely volumetric: repeated hook denials, denied secret-file reads, new MCP endpoints, unusual egress, many classifier blocks, attempts to disable policy, production credential requests from development sessions, or a burst of destructive API parameters.

Audit also closes the engineering loop. Teams can find noisy policies, false positives, unneeded capabilities, long-lived credentials, and workflows that repeatedly approach a dangerous boundary.

A Practical Control Matrix

The fastest way to expose gaps is to ask what each control does not stop.

Control	Primary decision	Does not replace
Enterprise identity	Who may start and own a session	Per-resource authorization
Managed MCP	Which capability providers may load	Tool-level and API-level policy
Permission rules	Which declared tools, paths, and commands may proceed	OS and network isolation
Local hooks	Dynamic checks around lifecycle events	Central inference inspection
Inference Hooks	Whether a transcript may proceed to governed inference	Process containment or response rewriting
Auto Mode	Whether a consequential proposed action appears safe	Deterministic deny and human approval
Sandbox/container	Which files, processes, and hosts are reachable	Business authorization at the service
Scoped credentials	What a session can authenticate to do	Correct model reasoning
OTel and Activity Feed	What happened and which policy decided	Prevention

If a design assigns two or three unrelated security promises to one row, it is probably overclaiming the control.

How I Would Roll This Out

Enabling every control in enforcement mode on day one is likely to break legitimate workflows and teach users to seek bypasses. I would use six stages.

Stage 1: Inventory

Discover active MCP servers, tools, permission overrides, plugins, hooks, network destinations, credential sources, repositories, and autonomous use cases. Separate read-only development tasks from production-impacting operations.

No allowlist is credible until the organization knows what it is allowing.

Stage 2: Establish hard red lines

Create managed denies for secrets, bypass mode, destructive version-control operations, direct production administration, and security-control modification. Enforce branch protection, service authorization, and default-deny network policy independently.

These controls should not wait for a classifier rollout.

Stage 3: Shadow the content policy

Deploy the Inference Hook in shadow mode. Measure request latency, payload distribution, 10 MB edge cases, data categories, false positives, endpoint availability, and the effect of proposed timeout behavior.

Build dashboards before blocking. A deny without an actionable reason and owner becomes a support queue.

Stage 4: Constrain capabilities

Move reviewed MCP servers into managed deployment. Enable managed-only mode for the pilot population. Split broad servers into narrower read and write services where possible, and require downstream authorization for every consequential tool.

Stage 5: Canary enforcement

Use percentage rollout and selected roles for the Inference Hook. Start Auto Mode with low-risk, reversible workloads in ephemeral environments. Review denied actions, classifier blocks, hook decisions, egress attempts, and user friction daily.

Stage 6: Expand autonomy by evidence

Increase scope only when the organization can show low policy noise, reliable incident correlation, narrow credentials, tested failure modes, and meaningful task outcomes. Grant longer execution time before granting broader production authority.

The mature metric is not “number of autonomous sessions.” It is the percentage of useful tasks completed inside policy with reviewable evidence and no expansion of standing privilege.

Failure Modes I Would Test Before Production

Security architecture becomes real during failure. My pre-production exercise would include:

The Inference Hook times out, returns malformed JSON, closes the connection, and becomes unavailable long enough to trigger the circuit breaker.
A transcript approaches and exceeds the documented 10 MB ceiling.
A valid webhook is replayed or sent with an invalid signature.
An approved MCP server changes URL, command arguments, certificate, version, or tool schema.
A repository tries to add an unmanaged server or broaden a managed permission.
Tool output contains a prompt injection and a realistic secret in the same result.
Auto Mode approves an intentionally overeager action.
A subprocess tries to read outside the workspace, use inherited credentials, call an unknown internet host, and reach production.
The credential broker receives a valid session identity for an unauthorized resource.
Security starts with one destination API event and reconstructs the user request, session, policy verdicts, credential, tool call, and code artifact.

I would also test the reverse problem: legitimate work under partial outage. A secure system that unpredictably blocks every developer will accumulate exceptions until it is neither secure nor usable.

Frequently Asked Questions

Is an MCP allowlist enough to prevent data exfiltration?

No. It controls which MCP providers may load. The agent may still read sensitive files, run shell processes, use allowed network destinations, or send sensitive context for inference. Combine MCP admission with permissions, Inference Hooks, egress controls, scoped credentials, and destination authorization.

Can Inference Hooks redact a secret and let the request continue?

Not currently. The documented decision is allow or deny. If content must be transformed, sanitize it before constructing a new governed inference request.

Do Inference Hooks inspect tool results?

They can inspect tool results when those results are included as tool_result blocks in the transcript for the next prompt event. There is no separate current tool-response or model-response event to enable.

Should the hook fail open or fail closed?

Choose by workload and document the consequence. Regulated or high-sensitivity work generally favors fail-closed with a highly available endpoint. Lower-risk development may use fail-open to preserve availability, but it should emit an alert and make the reduced protection visible.

Does Auto Mode replace permission prompts?

It reduces routine interruptions by applying explicit rules and background safety checks. Teams should still use ask for actions that require human judgment and deny for operations the agent must never perform.

Why not use Auto Mode as the final production gate?

Because it is probabilistic. Anthropic's published evaluation includes a 17% false-negative rate on 52 real overeager actions. Production authorization should be deterministic and enforced by the destination system.

Are managed settings impossible for users to bypass?

They provide central configuration, precedence, and locks inside the supported product path. They are not a substitute for controlling the machine, image, process, filesystem, and network when users or workloads have broader administrative access.

What should remain human-approved?

Irreversible or externally consequential actions: production changes, destructive data operations, IAM grants, security-policy changes, direct merges, legal or customer communications, and exceptions that widen the agent's own authority.

Can this architecture work for agents other than Claude Code?

Yes. The product mechanisms differ, but the control questions are general: who started the agent, which capabilities loaded, what data crossed inference, what action was proposed, what the process could reach, which credential was used, what the destination authorized, and whether the event can be reconstructed.

Final Take: Autonomy Needs More Boundaries, Not More Prompts

Enterprise agents are becoming useful precisely because they can continue through the loop: inspect, reason, call a tool, observe the result, adapt, and act again.

Stopping that loop every few minutes with a generic approval box is not a complete security strategy. People habituate to prompts, and autonomous sessions cannot wait for a human who is asleep or working elsewhere.

The better approach is to move policy to the places where it can be enforced precisely.

Use managed MCP to define the capability supply chain. Use deterministic permissions for non-negotiable action policy. Use Inference Hooks to put enterprise data rules directly before governed model calls. Use Auto Mode to review ambiguous consequential actions without pretending its classifier is infallible. Use sandboxing, network controls, and short-lived credentials to make an incorrect decision survivable. Use downstream authorization to protect the actual resource. Use telemetry and compliance events to tell one coherent incident story.

This architecture does not eliminate risk. It makes risk legible and bounded.

That is the standard enterprises should demand before increasing autonomy: not that the model always makes the right decision, but that no single wrong decision can quietly become an unbounded corporate action.

The new security stack is not built around trusting the agent more.

It is built around giving the agent exactly enough capability to finish the job, while every surrounding system remains prepared for it to be wrong.

Sources and Further Reading

About the Author

I am Suraj Khaitan, an AI and cloud engineer focused on production agents, Claude Code, MCP, RAG, and serverless architecture. I write practical deep dives for engineers who want to move past demos and build AI systems that are reliable, observable, secure, and economically sane.