Notifications
Clear all
Topic starter
20/08/2026 5:35 pm
TL;DR: AI governance must now track AI code assistants, MCP servers, models, packages, and secrets across the developer surface, then enforce authorization decisions where developers work, according to Cycode. The shift matters because discovery without control leaves shadow AI, unvetted data flows, and leaked API keys outside existing AppSec and identity governance models.
NHIMG editorial — based on content published by Cycode: AI Governance, From Visibility to Enforcement Across the Developer Surface
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.
Questions worth separating out
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.
Q: Why do AI assistants and MCP servers create new access-control risks?
A: They are not just productivity tools.
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.
Practitioner guidance
- 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.
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.
👉 Read Cycode's analysis of AI governance across the developer surface →
AI governance across the developer surface: are your controls keeping up?
Explore further
20/08/2026 6:21 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: AI governance moves from visibility to enforcement across developers
