They should scan repositories for model calls, agent workflows, tool integrations, and MCP references, then tie each finding to an owner and a reachable system. Discovery is only useful when it becomes an inventory of who can act on what and where the trust boundaries sit. That is the point where repository scanning becomes governance.
Why This Matters for Security Teams
Source code is often the first place AI usage shows up, but it is rarely documented cleanly. Teams may discover model calls, agent loops, or MCP references only after code is already moving toward deployment. That creates a governance gap: security can see that AI is present, but not yet who owns it, what it can reach, or whether the trust boundary is acceptable. Guidance from the NIST Cybersecurity Framework 2.0 reinforces that asset visibility must support risk decisions, not just asset counts.
This is why repository discovery should be treated as an inventory exercise with security outcomes, not a keyword scan. A finding only matters when it maps to a service owner, a deployment path, and the systems the code can influence. NHIMG research on the State of Non-Human Identity Security shows how often organisations lack confidence and visibility once non-human access expands, which is exactly what happens when AI code reaches production without being tied back to accountable ownership.
In practice, many security teams encounter risky AI usage only after a release candidate has already connected to production APIs, rather than through intentional pre-deployment discovery.
How It Works in Practice
Effective discovery starts by scanning repositories for the technical patterns that indicate AI behaviour: model SDK imports, prompt construction, agent orchestration, tool invocation, vector-store connectors, and MCP references. Those indicators should be grouped into a single inventory view so security can determine whether the code is a simple model integration or a workload that can plan, chain actions, and call external tools. The point is to distinguish passive inference from autonomous execution.
Discovery becomes more useful when each match is enriched with context. Teams should identify the repository owner, the deployment target, the runtime service account, and the systems reachable through APIs, databases, queues, and internal tools. This is where repository scanning connects to governance. A model call that stays inside a local notebook is not the same risk as an agent that can create tickets, trigger pipelines, or reach secrets stores.
Practitioners often combine code scanning with repository metadata and CI signals:
- scan for AI libraries, prompt templates, and agent frameworks
- detect MCP, tool-use, and workflow orchestration references
- tag findings to owners, environments, and application inventories
- verify whether the code can access secrets, tokens, or production data
For NHI-specific lifecycle thinking, the NHI Lifecycle Management Guide is a useful companion because discovery should feed registration, review, and revocation workflows, not sit in a backlog. For broader risk framing, NHIMG’s Ultimate Guide to NHIs explains why unmanaged non-human access quickly becomes a visibility problem. These controls tend to break down in polyglot monorepos and generated codebases because AI usage is abstracted behind wrappers, shared libraries, and environment-driven configuration.
Common Variations and Edge Cases
Tighter discovery often increases noise and review overhead, so teams have to balance coverage against the cost of triage. That tradeoff is real, especially when AI code is embedded in shared libraries, infrastructure templates, or generated pull requests where the original developer is no longer obvious. Current guidance suggests treating these as separate risk classes rather than applying a single rule set across all repositories.
One edge case is “AI-adjacent” code that does not call a model directly but still enables AI execution, such as webhook relays, prompt routers, or wrappers around third-party tools. Another is shadow use of AI inside scripts and notebooks that never pass through standard application scanning. In those cases, discovery should include build artefacts, workflow definitions, and CI/CD configuration, not just application source.
The operational question is whether the code can act on behalf of the organisation. If it can, the finding needs a named owner, a reachable system map, and a control decision before deployment. NHIMG’s Top 10 NHI Issues is useful here because hidden credentials and overbroad access are rarely isolated problems. For governance baselines, discovery should align to NIST CSF 2.0, but there is no universal standard yet for exactly how to classify every AI code pattern.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Discovery must catch agentic code paths before deployment. |
| CSA MAESTRO | MG-1 | MAESTRO addresses governance and visibility for agentic workloads. |
| NIST AI RMF | AI RMF supports identifying and managing AI deployment risk. |
Use AI RMF to classify AI code findings by impact, owner, and deployment context.
Related resources from NHI Mgmt Group
- How should security teams handle risks from AI browser extensions?
- How should security teams govern API keys used for generative AI access?
- How should security teams implement policy as code across Kubernetes and Terraform?
- How should security teams govern AI workloads across multiple cloud providers?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
