Enforcing policy on AI requests from applications you did not write

Policy belongs on the request, not in the application

Security teams often start from code ownership: if we cannot change the application, we cannot add controls. That framing does not fit AI traffic from commercial products. A prompt, a retrieved document or a tool call is a request that travels from the application toward a model, a tool or an MCP server. Wherever that request passes through something you operate, you can evaluate it against policy.

This matches the direction of OWASP guidance on excessive agency and MCP security, which favours boundary controls: complete mediation of downstream requests, permissions enforced at the tool boundary, and an MCP proxy or gateway for isolation between servers. It also states that prompt wording is not an enforcement boundary. Some of that guidance assumes enforcement in trusted application code. For software you cannot modify, an equivalent control has to sit outside the application, in the request path.

The first step is to classify what you are dealing with. Four categories cover most of it: AI features inside commercial SaaS products, where the vendor chooses the model and the endpoint; vendor-built agents that call tools on a user's behalf; browser-based AI sites that users reach directly; and coding assistants that send source code and context to models. Record for each one what it sends (prompts, files, credentials, tool arguments), where it sends it, and whether a person or the software initiates the call.

Where enforcement can sit, and what each placement can act on

No single placement covers every path. The table summarises what each can generally see and where it falls short for black-box applications. Actual capability depends on the product and how it is deployed.

• Network egress: Sees which destinations an application contacts, which makes it suited to blocking unapproved model endpoints. Content inspection needs decrypted traffic, and request-level actions such as redaction are limited when traffic is opaque.
• Proxy-based routing: Can evaluate full requests when traffic is directed through it, so allow, redact, block and rate limit are all feasible. It only covers applications that can be pointed at it or whose traffic is forced through it, and hard-coded vendor destinations can bypass it.
• Endpoint and browser: Reaches AI sites and coding assistants where users work, including traffic that never crosses a corporate network. Coverage depends on agent deployment, and it sees little of vendor-side calls made from a SaaS provider's own infrastructure.
• Model and tool access layer: Mediates calls to models and tools you provision, so permissions can be set per tool. It cannot see calls that an application makes with its own vendor-managed credentials.
• MCP server access: Tool calls pass through an identifiable protocol surface, so per-server and per-tool permissions and cross-server data flow monitoring are possible. It covers MCP traffic only, not the model prompt itself.

Constraints specific to third-party traffic

Encryption is the most common obstacle. A control that only sees destination hostnames can allow or block a connection but cannot redact a field inside a prompt. Content-level actions require the enforcement point to be a legitimate party to the connection, which is why proxy and endpoint placements are usually paired with network controls.

Vendor-controlled and hard-coded endpoints limit routing. If an embedded AI feature calls a model from the vendor's own environment, nothing on your network or endpoints may observe that call. In those cases the available levers are contractual, configurational or restrictive: disable the feature, constrain the data it can reach, or mediate the tools and data sources it is allowed to use from your side.

Non-human tool calls change what policy must express. An agent acting on a user's behalf can issue many calls from a single instruction, and tool inputs derive from model output that untrusted context may have influenced. Policy should therefore apply to every downstream call, not only the first request, and should treat tool responses as untrusted data, including responses from approved servers. The model also sees the tool descriptions of every connected MCP server, so one server can influence calls to another, which makes cross-server monitoring a separate control.

Define the enforcement policy set

Write policy per request path and per tool, not as one global rule. Start from an inventory of which tools and MCP servers each application can reach, reduce that to the minimum necessary, and apply least privilege per server and per tool. Then assign one of five actions to each class of request.

Before turning any pattern-based screening into a block, measure its false-positive rate on benign traffic. Single keywords such as "delete" or "reveal" misfire on ordinary requests, so match phrases and test first.

• Allow: Approved destinations, models and tools for a defined user group or workload. Record the decision, not only the exceptions.
• Redact: Remove sensitive fields such as secrets or personal data from a request or response, then let the rest proceed.
• Block: Stop requests to unapproved models, tools or MCP servers, and requests that carry data the policy prohibits leaving the environment.
• Rate limit: Bound the volume or frequency of requests or tool calls from an application, user or agent.
• Escalate for human approval: Require a person to confirm irreversible or high-impact actions, especially when the triggering input comes from untrusted content.

Runtime enforcement versus after-the-fact review

Reviewing vendor logs after an incident tells you what happened, if the vendor recorded it, in the format the vendor chose. OWASP guidance on logs from components you did not build notes that such records need separate evaluation of what they actually establish. Enforcement works differently: the decision is made before the request proceeds, and the enforcement point can record the request, the policy applied, the action taken and the outcome.

That makes evidence a by-product of enforcement rather than a separate collection effort. For a regulated enterprise, the question an auditor asks is what the application was allowed to do and what it did. Evidence produced at your own enforcement point answers both parts without depending on a vendor's logs. Evidence should still be handled carefully: redact secrets and personal data from stored records while keeping them usable, and set retention and data residency to match your obligations.

On the regulatory side, accountability for AI used through third-party software does not disappear because the vendor wrote the code. Regulation (EU) 2024/1689 is in force as of November 2026, and frameworks such as NIST AI RMF, HIPAA, NYDFS and NAIC are commonly used to structure accountability. Map your evidence to the specific requirements your counsel identifies, rather than assuming a log format satisfies them.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, at the level of individual interactions and tool calls. It generates audit-ready evidence from that enforcement, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST, and can be self-managed in the customer cloud.