AI governance moves from visibility to enforcement across developers

At a glance

What this is: This is an analysis of AI governance moving from inventory to enforcement, with the key finding that organisations need continuous discovery, authorization, and developer-surface guardrails for AI tools, MCP servers, and AI secrets.

Why it matters: It matters because IAM, PAM, and governance teams increasingly have to control not just human users, but the AI-enabled software paths where secrets, permissions, and tool access are being introduced.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Cycode's analysis of AI governance across the developer surface

Context

AI governance is no longer just a policy exercise. Developer workflows now include AI coding assistants, MCP servers, AI models, packages, and embedded API keys, which creates a governance gap when security teams cannot see what is being used or where it is connected. In practice, that turns AI adoption into an identity and access problem as much as an AppSec problem.

The core issue is that modern development environments are filling with software entities that request access, call APIs, and interact with data sources without the same lifecycle controls applied to human users. That makes AI inventory, authorization, and enforcement relevant to NHI governance, secrets management, and least-privilege control. For teams already dealing with shadow AI, the starting position described here is increasingly typical.

Cycode's article treats AI governance as a continuous control process rather than a one-time approval gate, and that framing is useful. The risk is not only exposure, but unmanaged tool proliferation that weakens auditability and enforcement across the developer surface.

Key questions

Q: How should security teams govern AI use in developer tooling?

A: Security teams should govern AI use as a data and access problem, not only a productivity feature. Define what information can be sent to models, require human review of generated code, and apply least privilege to connected repositories and tools. Approved use cases should be explicit, monitored, and revisited as model capabilities expand.

Q: Why do AI assistants and MCP servers create new access-control risks?

A: They are not just productivity tools. Many can read files, call APIs, access databases, and interact with external services, which means they operate inside the trust boundary normally reserved for approved software and users. Without scoped permissions and enforcement, they can become a fast path to secrets exposure and lateral movement.

Q: What breaks when AI governance starts with policy instead of inventory?

A: Policy-first programmes usually stall because teams cannot define scope, boundaries, or ownership with confidence. Without a credible inventory of agentic surfaces, controls are aimed at an incomplete estate, audit evidence is partial, and hidden access paths remain outside governance. The result is formal policy with weak operational reach.

Q: Who is accountable when a sanctioned AI tool causes a data breach?

A: Accountability should sit with the owner of the identity and permissions behind the tool, not only the team that approved the application. If a sanctioned AI workflow can reach sensitive data, the organisation must govern its access path, logging, and containment as rigorously as any other high-risk identity.

Technical breakdown

AI inventory as a living control surface

AI governance starts with discovery because teams cannot govern tools they cannot see. A living inventory differs from a static asset list by continuously cataloguing code assistants, models, infrastructure platforms, MCP servers, AI secrets, and ML dependencies as they appear in repositories and development workflows. That matters because the control objective is not simply classification. It is establishing a dependable source of truth for what is present, where it is used, and which combinations of tools expand the organisation's trust boundary.

Practical implication: build continuous discovery for AI artefacts before setting approval rules or enforcement thresholds.

Authorization states turn governance into an operational decision

A three-state model of needs review, authorized, and unauthorized is a practical way to translate inventory into action. Needs review creates a triage state for newly discovered AI technologies. Authorized records formal approval, while unauthorized creates an enforceable policy outcome. The value is in removing ambiguity. Once a tool is marked unauthorized, every subsequent use becomes a detectable governance violation rather than a subjective judgement call.

Practical implication: define explicit approval states for AI tools and wire them into case management and policy enforcement.

MCP guardrails and developer-surface enforcement

MCP servers are different from ordinary developer extensions because they can execute commands, access files, call APIs, and bridge external services based on natural language prompts. That makes them a high-risk control point for identity and privilege abuse in AI-enabled development. Guardrails such as blocking unauthorized MCPs or limiting execution to localhost are enforcement patterns, not just monitoring patterns. They reduce the chance that a governance decision stays trapped in policy while the developer environment ignores it.

Practical implication: enforce MCP restrictions inside the IDE or equivalent runtime entry point, not only in policy documentation.

Threat narrative

Attacker objective: The attacker objective is to exploit unmanaged AI tooling and connected identities to reach code, secrets, and downstream systems through the developer workflow.

1. Entry occurs when developers add AI assistants, MCP servers, packages, or API keys into the toolchain without security visibility.
2. Escalation happens when those tools gain access to files, APIs, databases, and connected services through broad permissions or trusted integrations.
3. Impact follows when unapproved tools leak secrets, move data into unvetted services, or extend access beyond approved development boundaries.

NHI Mgmt Group analysis

AI governance is now an identity governance problem, not just an AppSec problem. Once AI assistants, MCP servers, and AI service keys enter day-to-day development, the question becomes who or what is allowed to act, call tools, and touch data. That shifts the control conversation toward access review, authorization state, and blast-radius reduction. Teams that keep treating AI governance as a standalone policy layer will miss the real control surface.

Shadow AI creates a named governance gap: discovery without enforcement. Inventory alone does not reduce risk if the organisation cannot block or constrain unauthorized tools where developers actually use them. This is the point where AI governance becomes operational, because policy needs to be enforced in the environment that can execute the action. Practitioners should expect this control gap to widen as developer adoption outpaces formal review processes.

MCP servers concentrate privilege in a form that conventional extension management does not fully capture. They can read, write, call, and chain actions across connected systems, which means the security model has to account for both tool trust and delegated access. That is why least privilege, approval workflow, and execution scope should be evaluated together. The practical conclusion is that MCP governance belongs in both AI security and NHI governance conversations.

AI governance will increasingly be measured by how fast organisations can move from detection to decision to enforcement. A mature programme does not stop at finding an unapproved model or package. It records the approval state, maps ownership, constrains execution, and leaves an audit trail that compliance teams can defend. That makes governance an operating capability rather than a periodic review exercise.

Developer-surface enforcement is the direction the market is moving because policy-only governance is too easy to bypass. Security teams should expect more pressure to prove that controls exist at the point of use, not just in a registry or spreadsheet. The field is converging on practical enforcement over declarative approval, and practitioners should align their roadmaps accordingly.

What this signals

AI governance roadmaps will increasingly be judged on whether they can connect discovery, authorization, and enforcement in one workflow. That mirrors the broader shift in identity security from visibility to control, where unmanaged software entities must be treated as governed actors rather than passive tooling. For teams aligning to NIST Cybersecurity Framework 2.0, the lesson is to make this measurable across identify, protect, and respond functions.

Developer-surface governance debt: this is the gap between knowing AI tools exist and being able to stop unapproved use at the point of execution. Once that debt accumulates, teams spend more time reconciling exceptions than reducing exposure. The right response is to connect AI inventories with policy enforcement and secret management so that approval decisions survive contact with the developer workflow.

The most practical near-term signal is whether organisations can map AI tools to owners, data paths, and privilege boundaries without manual chasing. That aligns with broader control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access control, configuration management, and auditability.

For practitioners

• Implement continuous AI inventory Track AI code assistants, MCP servers, models, packages, and AI secrets as live assets across repositories and developer environments, not as one-time survey results.
• Define explicit authorization states Use needs review, authorized, and unauthorized states for every discovered AI tool so security decisions can be operationalized and audited consistently.
• Enforce MCP restrictions at the developer surface Block unauthorized MCP connections and restrict approved MCP execution to localhost-only or similarly bounded contexts when remote access is not required.
• Tie AI governance to secrets and identity controls Treat API keys, tokens, and connected service permissions as part of the same governance workflow so AI adoption does not bypass NHI and secret management controls.
• Create exception handling for approved but risky tools Apply tighter policy and review for permitted AI tools that can reach production systems, customer data, or cross-service integrations.

Key takeaways

• AI governance fails when organisations can see tools but cannot stop unapproved ones from being used.
• MCP servers and AI secrets turn developer workflows into identity-sensitive control points that need explicit authorization.
• The next maturity step is enforcement at the developer surface, where policy becomes a real control instead of a registry entry.

Key terms

• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• 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.
• AIBOM: An AI Bill of Materials is a structured inventory of the components, data sources, prompts, connectors, and dependencies that shape an AI system. It helps security teams understand what the model can access, where risk enters the stack, and which changes require governance review.

What's in the full article

Cycode's full article covers the operational detail this post intentionally leaves for the source:

• The live AI inventory and knowledge graph mechanics used to trace AI tools across repositories and developer environments.
• The exact authorization workflow logic for needs review, authorized, and unauthorized states.
• The IDE-level MCP guardrail behaviour that blocks unauthorized use before execution.
• The custom policy examples for shadow AI, unapproved models, and team-level AI risk.

👉 Cycode's full article covers AI inventory, authorization workflows, and MCP guardrails in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It gives practitioners a shared control language for managing identities and access across modern environments.