Runtime Enforcement Without a Gateway

Runtime enforcement without a gateway is a control model that blocks or allows an AI agent's actions at the identity and app-access layer instead of routing every call through an inline proxy. The distinction matters because the word "enforcement," on its own, tends to scare infrastructure and platform teams. They hear it and picture a new box in front of every agent action: a latency tax, a fresh single point of failure, and a blast radius amplifier if the box ever misbehaves.

The pushback is rational. Security engineers have watched web application firewalls buckle under load. They have sat through outages caused by inline decryption appliances during a certificate rotation. Asking them to sign off on another intermediary, this time in front of every Copilot or Agentforce action, is asking them to relive a bad memory.

And it stalls deals. When a CISO says "we need runtime enforcement for our agents," the platform team often hears "we need to break our Microsoft integration to install your proxy." Those are not the same sentence. The proxy is one architecture for enforcement. It is not the only one, and for identity-based agent risk it is usually the wrong one.

Gateway-based enforcement inherits three costs from its heritage as a box in the request path. Buyers who have run inline tooling before can name all three from memory.

Latency. Every action takes a synchronous round trip through the decision engine before the target app ever sees the request. A chat agent doing multi-step reasoning can fire ten tool calls in a single task, and a full second of stacked decision latency lands on top of model inference the user already waited for.

Single point of failure. If the inline proxy goes down, agent workflows stop with it. Business users lose Copilot, Agentforce, and Bedrock at the same moment, for a reason that has nothing to do with those platforms. Security tooling should not be able to take production AI offline.

Blast radius. An inline proxy reads every prompt, every response, and every tool argument. That concentrates a large volume of sensitive data in one system, and that system becomes a high-value target in its own right. You added a control and created an attack surface in the same motion.

These are the trade-offs infrastructure teams actually weigh in the room. They are also the reason "runtime enforcement without gateway" is a phrase buyers now type into a search bar on purpose.

The two enforcement layers answer different questions, and confusing them is where most architecture arguments go sideways. A network gateway asks where the data is going. An access-layer engine asks who the agent is acting for and what its identity can reach.

Neither one replaces the other. Choose access-layer enforcement when the risk lives inside the identity and permission model. Choose a network gateway when the risk is content leaving your network. Most enterprises end up running both, and that is fine. The problem is not the gateway. The problem is a forced dependency on a gateway to make identity-based agent decisions it was never built to make.

Source-side enforcement works for one reason: the decision engine already knows the answer before the action fires. It has mapped each agent's effective access in advance, so the block decision is a lookup, not an inspection.

Effective access is concrete. It is not the permission a vendor's configuration page implies an agent might have. It is what the agent's identity can genuinely reach at runtime: which service account it authenticates as, which Salesforce objects or Snowflake tables that account can read, which actions it can trigger such as export, delete, or post to an outbound connector, and which other agents it can call. Correlating an agent's live activity to that real effective access, rather than to the vendor's theoretical configuration page, is the whole difference between governance and paperwork.

The maker-mode case a gateway cannot see

Take the confused-deputy pattern. A user with no Salesforce access invokes an Agentforce agent that a Salesforce admin built. The agent runs on the admin's embedded credentials, so its token is completely legitimate. The user asks for restricted CRM data. A gateway watching this traffic has no basis to object, because the token is valid and the request looks correct on the wire.

The access-layer engine sees the correlation the wire hides. It knows the person triggering the agent does not hold Salesforce access. It knows the agent is running in maker mode on admin credentials. It reads that combination as a machine insider borrowing authority it should never spend on this requester, and it denies the action at the platform's own control plane rather than on the network. That is runtime truth in place of theoretical configuration.

Where the block actually happens

The engine hooks into control-plane events, not data-plane traffic. AI platforms expose native APIs and event streams for agent lifecycle, tool invocation, and access decisions. The engine subscribes, evaluates the request against the identity graph and policy, and where the platform supports a synchronous decision it returns allow or block within a sub-second window that runs in parallel with the platform's own auth flow. When a block is warranted, the engine calls the platform's control API to deny the tool call, revoke the session, or quarantine the agent. This is an "Intel Inside" decision-engine model, not an inline gateway. Obsidian never sits in the request path.

Be exact about what ships today. Autonomous runtime blocking is live for Anthropic Claude and Microsoft Copilot only. For every other platform, including Agentforce, Snowflake Cortex, ServiceNow Now Assist, Moveworks, Bedrock, Vertex, and n8n, the model is discover and govern: full inventory, effective-access mapping, policy, and reporting are available now, with runtime enforcement on the roadmap rather than in production. Do not let that boundary blur.

Access-layer enforcement does not cover everything, and claiming otherwise would be its own kind of dishonesty. Keep gateway or proxy controls for the work they do genuinely well:

• Prompt-level DLP on outbound traffic to shadow AI apps opened from a managed browser.
• Egress restrictions for locally run models such as on-device assistants or on-prem inference that no access-layer tool can observe.
• Network isolation between agent workloads and sensitive backend systems.
• Content filtering on data leaving your network for a third-party AI provider.

Obsidian makes no claim on on-prem or on-device agent coverage. Those workloads live below the control-plane hooks the access layer depends on, and they need network controls. What the access layer covers is the third-party deployed agent ecosystem across the major AI platforms, where native APIs make source-side enforcement possible. Draw the line honestly and the two controls stop competing and start covering each other's gaps.

The deployment differences are not marketing. They decide whose calendar you need before anything ships.

Access-layer enforcement is faster to stand up because it never touches data paths, DNS, or certificate chains. There is no sidecar, no service mesh, and no forced traffic rerouting, which means a security team can deploy on its own risk mandate without waiting on SaaS admins or network engineers to approve an inline change. That autonomy is the operational payoff: one control plane over agents across every connected platform, fewer fire drills, and evidence that generates itself instead of being reassembled by hand.

The trade the model asks you to accept is honest scope. It enforces where platform hooks exist, which today means blocking on Claude and Copilot and discover-and-govern everywhere else. For identity-based agent risk, that is the coverage that matters first, and it arrives without a new box in the critical path.