Which frameworks should guide governance for exposed AI services and connected tools?

Why This Matters for Security Teams

Exposed AI services are not just another application tier. They can accept prompts, call tools, retrieve data, and trigger downstream actions, which means governance must cover model behaviour, access scope, logging, and revocation as a single control problem. The right framework set helps security teams separate model risk from infrastructure risk, while still tying both to accountable ownership and measurable controls. NIST’s NIST Cybersecurity Framework 2.0 remains useful because it links governance to risk management, protection, detection, response, and recovery rather than treating AI as a standalone exception.

What many teams miss is that “AI service exposure” often includes API endpoints, orchestration layers, tool connectors, and delegated identities that can be abused even when the model itself is behaving as designed. OWASP Agentic AI and MITRE ATT&CK are valuable here because they help map misuse patterns such as prompt injection, tool hijacking, indirect data leakage, and adversary use of legitimate access paths. In practice, many security teams encounter the real governance failure only after a tool-enabled AI workflow has already accessed data or executed an action that nobody can clearly revoke.

How It Works in Practice

A practical governance model starts by assigning one framework to answer “who owns the risk,” another to answer “what attack patterns matter,” and a third to answer “how access is controlled.” NIST AI RMF is the primary governance lens for identifying, measuring, and managing AI risk across the system lifecycle. NIST CSF then anchors the broader cybersecurity program so the exposed AI service is treated like any other critical service with defined controls for identity, logging, protection, and incident response.

For implementation, teams should document the exposed surfaces, then map each one to a control owner and a response path. That includes the model endpoint, retrieval layer, agent runtime, external tools, and any service account or NHI used to access them. Where the service can act on behalf of a user or workflow, the delegated identity should be governed with least privilege, short-lived authorization, and explicit revocation paths. Guidance from Anthropic — first AI-orchestrated cyber espionage campaign report is a reminder that misuse can emerge through the orchestration layer even when core model protections appear intact.

• Use NIST AI RMF to define ai governance, assurance, and accountability.
• Use NIST CSF 2.0 to fold AI services into enterprise risk, detection, and response processes.
• Use OWASP Agentic AI to test prompt, tool, and autonomy abuse paths.
• Use MITRE ATT&CK to model post-compromise behaviour and defender coverage.
• Apply NHI controls when tools, APIs, or data sources are reached through delegated credentials.

These controls tend to break down when AI services are assembled from multiple unmanaged tool connectors and shadow service accounts because ownership, telemetry, and revocation become fragmented across teams.

Common Variations and Edge Cases

Tighter governance often increases delivery overhead, requiring organisations to balance faster experimentation against stronger control over tool use, identity scope, and review gates. That tradeoff is especially visible in agentic deployments, where business teams want autonomy and security teams need predictable limits.

Best practice is evolving for fully autonomous agents, so there is no universal standard for this yet. Some environments can treat an AI service like a conventional application with added model-specific testing, while others need explicit approval workflows for every external tool or sensitive dataset. The right choice depends on how much execution authority the service has and whether it can modify records, trigger payments, or move data between trust zones.

Identity boundaries become especially important when a service uses a persistent token, shared API key, or broad cloud role to access multiple systems. In those cases, NHI governance should be treated as part of AI governance, not an afterthought. If the service also touches regulated data or critical operations, governance should extend to evidence collection, change control, and incident escalation so the organisation can prove who authorised what and when.

For teams formalising a baseline, pairing NIST AI RMF with NIST CSF 2.0 is the most defensible starting point, then layering OWASP Agentic AI and ATT&CK for abuse-case coverage. When the environment involves high-value workflows, the supporting controls should also align with rigorous identity practices and revocation discipline, not just model safety checklists.

Related resources from NHI Mgmt Group

• Who should own governance for MCP tools inside AI environments?
• Which frameworks should AI observability map to for governance evidence?
• Which frameworks should organisations use for AI-SPM and agent governance?
• What makes agentic AI an NHI governance issue?