What should organisations do first when building enterprise AI security?

Why This Matters for Security Teams

Enterprise AI security fails early when organisations treat models, agents, plugins, and connected data sources as isolated experiments instead of operational systems with real access. The first priority is discovery because untracked AI components can quietly inherit secrets, reach internal services, and expand the blast radius of a simple configuration mistake. That is especially true for autonomous or semi-autonomous agents, where behaviour changes with prompts, tools, and context rather than staying fixed.

Current guidance suggests starting with visibility into every AI-facing dependency, then classifying what each component can read, write, or trigger. That means models, agent runtimes, MCP-style integrations, vector stores, browser tools, and vendor APIs all belong in scope. NHIMG research has shown how visibility gaps persist even in adjacent identity problems: The State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps. Security teams should treat AI the same way, because hidden connections are where policy blind spots form. In practice, many security teams encounter the first AI exposure only after a connected system has already been over-permissioned or a model has touched sensitive data unexpectedly.

How It Works in Practice

Discovery for enterprise AI security should begin as a control exercise, not a documentation task. Build a living inventory that records each model, agent, extension, workflow, and external service, plus the secrets and identities they use. NHI Management Group recommends classifying every AI component by the data it can access, the actions it can execute, and whether those permissions are static or issued just in time. That distinction matters because autonomous systems rarely behave like human users with stable access patterns.

From there, map runtime paths, not just intended architecture. If an agent can call a ticketing API, reach a code repository, or invoke an internal search service, those connections need explicit ownership and logging. The CSA MAESTRO agentic AI threat modeling framework is useful here because it frames agent risk around tool use, orchestration, and trust boundaries. For implementation discipline, Anthropic Project Glasswing is a reminder that AI systems should be evaluated with their broader operational context in mind, not just model output quality.

• Inventory all AI assets, including shadow IT and vendor-managed integrations.
• Identify every secret, token, certificate, and OAuth grant tied to AI workflows.
• Classify permissions by business function, data sensitivity, and tool reach.
• Apply monitoring that captures prompts, tool calls, approvals, and downstream effects.
• Review whether access can be reduced to ephemeral, task-scoped credentials.

Discovery should also include where AI systems are embedded inside existing products, because that is where governance often fragments between procurement, security, and engineering. These controls tend to break down when AI is deployed through unmanaged SaaS add-ons and browser-based extensions because ownership is diffuse and runtime behaviour changes faster than change management can track.

Common Variations and Edge Cases

Tighter discovery and classification often increases operational overhead, requiring organisations to balance speed of adoption against confidence in control. That tradeoff is real, especially in teams running rapid prototyping, external copilots, or multiple LLM providers at once. Best practice is evolving, and there is no universal standard for what an AI asset inventory must include yet, but incomplete visibility is a known source of governance failure.

One common edge case is third-party AI features embedded in existing platforms. Those features can inherit enterprise permissions without appearing in normal asset registers, which makes them easy to miss until data leaves the expected boundary. Another is agentic automation, where a single workflow can chain multiple tools and create effects far beyond the original request. In those environments, discovery should extend beyond the model itself to the full execution path, including prompts, retrieval sources, browser actions, and delegated credentials.

For deeper context on why hidden identity paths matter, see Ultimate Guide to NHIs — Why NHI Security Matters Now and the DeepSeek breach. Organisations that delay discovery until after deployment usually discover too late that the AI system was never a single system at all, but a chain of identities, secrets, and tool calls.

Related resources from NHI Mgmt Group

• Why is single-provider AI agent governance not enough for enterprise security?
• How should organisations decide whether to buy AI security tools through procurement channels?
• What should teams prioritise first when aligning AI RMF with existing security programmes?
• How should security teams handle risks from AI browser extensions?