What a Paved Road for AI Is, and How Runtime Policy Enforcement Makes It Enforceable

What a paved road for AI is

In platform engineering, a paved road (often called a golden path) is the supported route for building and running software. It bundles approved components, sensible defaults and tooling so that the secure, compliant choice is also the easiest one. Teams adopt it because it removes work, not because they are forced to.

Applied to AI, the paved road covers more than a model list. It is the set of approved choices and defaults that platform teams publish for every way the organization uses AI. The components below are the ones most platform teams need to define.

The road is a design artifact. It says where traffic should go. It does not, on its own, say anything about where traffic actually goes.

• Approved models: The models teams may call, with the conditions under which each may be used.
• Approved tools and MCP servers: The tools and MCP servers an agent may invoke, and the actions permitted on each.
• Reference patterns: Standard ways to build agents, AI sites and integrations so teams do not start from scratch.
• Sanctioned coding assistants: The assistants developers may use and the rules for code that flows in and out.
• Defaults and policy: Baseline settings and the rules that define what is allowed for data, actions and users.

Why a paved road without enforcement is only guidance

Most organizations maintain the road through documentation, review boards and after-the-fact audit. Each of these has a role, but none sits where AI behavior happens. A review board approves a system at a point in time. An audit examines what already occurred.

NIST AI 600-1, the Generative AI Profile of the AI Risk Management Framework, notes that risks can arise during design, development, deployment and operation. It also includes an action to set minimum thresholds and review them as part of deployment approval (go/no-go) processes. That is a pre-deployment gate, and it is a sound control. It cannot, by itself, determine what a particular interaction or tool call does once the system is running.

This leaves a gap between what AI is allowed to do and what it does. A team with a direct API key, an unsanctioned assistant or an unreviewed MCP server can step off the road without any signal reaching the platform team. The result is unmanaged risk. It also means security, platform and compliance leaders cannot show a regulator or auditor that policy was applied to individual interactions, only that a policy existed.

Placement, bypass resistance and tradeoffs

Enforcement can be placed in several ways: a gateway or proxy that traffic is routed through, an SDK embedded in applications, a sidecar next to a workload, or an agent on the endpoint. Each trades coverage against effort. An SDK depends on teams adopting it, so a team that skips it is also skipping enforcement. A proxy covers whatever is routed through it, so network rules that stop direct egress to model endpoints matter as much as the proxy itself.

Heterogeneity is the harder problem. Models, agents, tools, MCP servers, AI sites and coding assistants each connect differently. If each needs its own control with its own rules, policy drifts. The aim is one policy definition applied consistently across all of them, with a clear view of which paths are covered and which are not.

Placing enforcement in the path also creates operational responsibility. It adds latency and becomes a dependency for AI traffic, so teams must decide deliberately whether a failure of the enforcement point fails open or fails closed, and test that behavior. Policy changes need versioning, testing and staged rollout, as any production change does.

Audit-ready evidence and where Trussed fits

Evidence is the second half of enforcement. Guidance for agentic security from OWASP includes aligning control evidence with frameworks such as the EU AI Act, NIST AI RMF and ISO/IEC 42001. The EU AI Act, Regulation (EU) 2024/1689, is described by the European Commission as the first legal framework on AI. As of November 2026, it is the in-force regulation most teams map their evidence to. Evidence generated by enforcement is stronger than evidence reconstructed later, because each record comes from the decision itself.

Trussed provides control, provenance and evidence infrastructure for the regulated enterprise. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with allow, redact, block, rate limit and escalation for human approval, scoped to individual interactions and tool calls. Enforcement produces continuous audit-ready evidence mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency. Trussed also provides code provenance: the origin, licence and security context of code.

In production, Trussed has run continuously for 18+ months in a regulated enterprise at 99.95% uptime on live traffic, with 100+ models under one policy plane and 30+ GB of audit evidence generated per day.