Agent routing shifts AI coding control from tickets to governed access

At a glance

What this is: Tetrate describes a governed access model for AI coding assistants that combines project-scoped provider grants, model allow-lists, budgets, and self-service keys in one gateway.

Why it matters: IAM, IGA, and platform teams need this pattern because AI developer adoption is pushing model access, credential handling, and spend control into the same governance boundary.

Context

AI coding assistants are now part of the developer workflow, which means model access is becoming an identity and governance problem, not just a tooling choice. When providers, budgets, and keys are handled through tickets or shared secrets, oversight slows down the very users the system is meant to enable.

The article frames Tetrate Agent Router as a way to move that control plane into the gateway. For identity teams, the important shift is that access scope, credential issuance, and budget enforcement are being treated as policy objects tied to a project, not as ad hoc developer exceptions.

Key questions

Q: What breaks when AI model access is controlled by the provider instead of the customer?

A: The customer loses continuity when the provider or a regulator revokes access, even if the customer has done nothing wrong. That means workflows, approvals, and downstream services can fail instantly because the control plane is external. The practical failure is not model quality, but loss of authority over the entitlement that keeps the model available.

Q: Why do project-scoped AI credentials reduce risk in developer tools?

A: They reduce risk because the credential is bound to a specific project, not to a developer’s personal provider relationship. That lets teams align model access, spend limits, and audit logging to one boundary, which is far easier to govern than many per-extension or per-vendor secrets scattered across the environment.

Q: What do security teams get wrong about AI cost control?

A: They often treat cost as a finance-only issue and overlook the identity layer that drives usage. Without attribution, shadow AI discovery, and policy enforcement at the request path, teams can reduce waste in one area while leaving the real source of token growth untouched.

Q: How should teams govern AI-assisted development workflows that use coding agents?

A: Treat them as identity-governed execution paths, not just productivity tools. Define who can start the workflow, which tools and data sources it can reach, what evidence is required for review, and how access is revoked if the workflow expands beyond its intended scope. The key is to govern the chain of delegated action, not only the final code output.

Technical breakdown

Project-scoped provider grants and model allow-lists

Agent Router uses two layers of approval: the organization catalog decides which providers and models exist at all, and the project grant decides which of those a specific project may use. That means a request only succeeds when both layers agree. In practice, this turns model access into a bounded entitlement model rather than a free-form API key sprawl problem. The allow-list is stronger than a UI control because unsupported model requests are rejected at request time, not merely hidden from view.

Practical implication: treat model access as entitlement policy and review both catalog-level and project-level grants together.

Budget enforcement as a governance control

The budget layer is not just billing visibility. It defines whether a team, user, or single key can continue making requests once spend reaches a limit, and it supports watch, hard stop, or graceful degradation modes. That makes cost control part of the access model, because a credential can be valid but still functionally constrained by policy. The article also notes that enforcement is eventually consistent and fails open while usage totals catch up, which is acceptable for finance ceilings but not for emergency interruption.

Practical implication: pair spend budgets with separate inline controls when you need an immediate cutoff.

Developer-issued inference keys and editor integration

The developer flow creates a project-scoped inference key once, then uses a project Base URL and an extension-backed model provider inside VS Code. The key is shown once, stored in OS-keychain-backed secret storage, and then tracked through masked display and last-use metadata. That is a better control pattern than distributing provider-specific secrets to every extension, because it gives the organisation one credential boundary and one audit path across the editor, terminal, and agent surfaces.

Practical implication: centralise AI credentials at the project boundary and keep editor extensions from becoming separate secret-distribution channels.

Threat narrative

Attacker objective: The objective is to gain unauthorised or unmanaged access to AI models and their associated spend and data flows.

1. Entry occurs when developers or agents consume AI services through project-scoped inference keys and gateway endpoints rather than direct provider credentials.
2. Escalation happens if provider grants, model grants, or budgets are left broader than the project actually needs, letting requests expand beyond intended scope.
3. Impact is governance drift: uncontrolled model choice, scattered keys, and untracked spend create shadow AI and weaken the organisation's approval boundary.

Breaches seen in the wild

• Amazon Q MCP config vulnerability 2026: A malicious .amazonq/mcp.json in a repository could make Amazon Q run commands with a developer's AWS credentials. Fixed before disclosure.
• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agent routing is becoming an identity boundary, not just an API convenience: once developers can self-serve model access from a governed gateway, the control point shifts from procurement tickets to entitlement design. That changes how IAM, platform engineering, and security teams should think about model access, because the project boundary now carries real governance weight. Practitioners should stop treating AI model selection as a purely developer experience issue and manage it as scoped access.

Cost control and identity control are now entangled: a budget attached to a team or key is effectively a usage entitlement with financial consequences. The article shows that spend policy, model policy, and credential policy can no longer be separated cleanly when AI assistants are embedded in the editor. Teams that govern keys without governing spend, or govern spend without governing model scope, leave a gap in the control plane.

Shadow AI emerges when governance is slower than enablement: if approved access is too hard to obtain, developers route around it with unmanaged keys and private provider accounts. That is not a tooling defect, it is a programme design failure. The right response is not more friction at the edge, but a tighter project-level model for who may use which providers, under what budgets, and through which credentials.

Project-scoped inference key is the right named concept for this pattern: the key is not merely a credential, it is the unit that binds editor use, model access, and spend to a governed project context. That concept matters because it collapses several governance questions into one auditable boundary. Practitioners should think in terms of project-scoped inference keys whenever AI assistants are allowed to operate inside production engineering workflows.

Vers VS Code and agent surfaces broaden the governance problem beyond web apps: once the same key can drive chat, agent mode, and extension calls, the identity surface becomes the developer environment itself. That makes editor-integrated AI a workload identity problem as much as a user convenience problem. Identity programmes should account for where the credential lives, how long it persists, and what else it can reach.

From our research library:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Project-scoped inference keys: this pattern gives identity teams a concrete way to bind AI assistant use to a managed project boundary instead of a developer’s personal provider accounts. That matters because the control point shifts from ad hoc approvals to a lifecycle that can be reviewed, revoked, and audited like any other non-human identity.

The governance lesson is broader than AI coding. When model access, budgets, and editor integrations converge, identity teams need a single entitlement model that spans secrets, spend, and auditability, rather than three disconnected controls. That is the shape of the next NHI governance problem, whether the actor is a developer tool, an agent, or a workload.

For practitioners

• Define project-level AI entitlement boundaries Scope approved providers, models, and MCP access by project rather than by individual developer preference, so requests are evaluated against one governed boundary.
• Treat inference keys as governed credentials Issue one project-scoped inference key per approved workflow and track last use, creation date, and masked display so abandoned credentials can be identified and revoked.
• Separate budget policy from emergency cutoff controls Use team or key budgets for spend ceilings, then pair them with an immediate inline control when requests must stop without waiting for usage rollups.
• Review editor and agent integrations for secret sprawl Check whether VS Code extensions, terminal tools, and agent frameworks are all drawing from the same governed key store instead of creating parallel secret paths.
• Build last-use review into NHI cleanup Use masked key listings and last-used telemetry to find stale AI inference keys that no longer support active projects or approved model access.

Key takeaways

• AI coding assistant access becomes much easier to govern when providers, models, budgets, and keys are tied to a project boundary instead of being managed as separate tickets and shared secrets.
• The main control challenge is not just who can use a model, but how to keep spend limits, credential scope, and approved model lists aligned as developers self-serve from inside their tools.
• Identity teams should treat editor-integrated AI as a governed non-human access pattern and review it with the same discipline they apply to other project-scoped credentials.

Key terms

• Project-Scoped Inference Key: A project-scoped inference key is a non-human credential tied to one governed project rather than a personal account. It lets organisations bound model access, usage logging, and revocation to a single operational unit, which is especially important when developers use AI tools inside IDEs and agents.
• Model Allowlist: A model allowlist is a centrally approved set of AI systems that users are permitted to access for defined tasks. In governance programmes, it limits data exposure, reduces shadow usage, and ensures the organisation can validate security, privacy, and compliance requirements before a model is used.
• Budget Enforcement: Budget enforcement is the control that stops or alters requests once spending reaches an approved threshold. In AI workflows, it is not just a finance feature, because it directly affects whether a credential can continue to operate and whether usage remains inside the intended governance boundary.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.