Homegrown AI Control Plane Risk: Key-Person Dependency and Coverage Gaps

Where key-person dependency arises

In-house enforcement layers usually start as a small project: a proxy in front of one model, a policy service, perhaps a tool-call interceptor for one agent framework. The engineers who build it make many design decisions that never reach a document. Why a rule redacts instead of blocks, which exceptions were granted to which team, and how the service behaves under load all live in a few heads.

This becomes an operational risk when those people change roles or leave. Policy logic that is undocumented cannot be reviewed by a security or compliance function, and it cannot be safely modified by anyone else. On-call is a related weak point. If only the original authors can diagnose the layer, every incident depends on their availability, and the layer sits in the request path of the AI systems it protects.

The NIST AI Risk Management Framework notes that actors in charge of one part of the AI process often lack full visibility or control over other parts. An enforcement layer owned informally by one team, but relied on by many, is a concrete example of that pattern. The practical test is simple: could someone who did not write the layer explain what it enforces today, and change a rule without breaking something else?

Where enforcement coverage gaps arise

Coverage gaps are usually architectural. A control placed at one point, such as a model proxy, sees model prompts and responses. It does not by itself see an agent's tool calls, a request to an MCP server, or a coding assistant that talks to its own backend. Each new surface needs its own integration, and until that integration is built the surface is either unmonitored or logged without being enforced.

The surfaces that matter are widening. NIST conference material describes agents misusing legitimate tools through prompt manipulation or privilege control, with outcomes such as data exfiltration, unsafe operations and workflow hijacking. It also places control at the consequence-producing boundary, the point where an action takes effect. Enforcement that covers only model traffic leaves that boundary unaddressed. OWASP states that MCP introduces risks traditional API security cannot fully address, and recommends gateway controls such as protocol validation and rate limiting, plus centralised logging of tool calls, data requests and errors. If an organisation hosts its own MCP servers, segmentation, gateway controls and tool vetting become its direct responsibility.

Coverage and evidence are linked. A path that is not instrumented produces no record, so the gap shows up twice: once as an unenforced action and again as a hole in the evidence trail.

Why evidence and regulatory expectations stress a custom layer

As of November 2026, the EU AI Act sets deployer expectations for high-risk systems that include appropriate technical and organisational measures, monitoring of operation and record-keeping. People overseeing such systems must be able to detect and address anomalies, dysfunctions and unexpected performance. The NIST Generative AI Profile calls for post-deployment monitoring processes that are established, maintained and evaluated for effectiveness.

A homegrown layer is tested hardest by these expectations. Records that differ by integration, policy logic nobody can explain, and monitoring processes that exist only in practice are difficult to defend. Evidence that is complete for the first model proxy but absent for a later MCP server will not read as a consistent control. Retention is a design decision that has to be made explicitly, because logs kept for debugging are rarely kept for audit purposes.

Requirements differ by regulator and by system, so map each obligation that applies to your estate to a specific record the layer produces, rather than assuming the logs will suffice.

Deciding what to keep in-house and what to evaluate

The review should end in a split decision rather than a blanket one. Policy intent usually belongs in-house: which data classes may leave, which actions need human approval, and which exceptions are acceptable are business and risk decisions. Enforcement mechanics are different. Protocol handling, per-surface integration, availability engineering and durable evidence storage are ongoing engineering work that grows with each new model, agent or tool.

A reasonable rule is to keep what your team can own, document and staff with redundancy, and to evaluate a purpose-built runtime enforcement product for the rest. Where a criterion above is not met and cannot be fixed with current headcount, that is the candidate for evaluation. Where the in-house layer scores well, it may be worth retaining, with the coverage map and succession plan kept current.

For teams that do evaluate a product, Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with actions that include allow, redact, block, rate limit and escalate for human approval. Enforcement applies to individual interactions and tool calls, and it produces continuous audit-ready evidence mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. It deploys self-managed in the customer cloud, with configurable retention and data residency. Trussed has run 18+ months in continuous production in a regulated enterprise, at 99.95% uptime on live production traffic, with 100+ models under one policy plane. Judge any product against the same criteria you applied to your own layer.