Open source AI security tools are reshaping agent governance

At a glance

What this is: Open source AI security tools are being positioned as the governance layer for agentic systems, with Obot arguing that runtime access control and auditability matter more than model-only safety.

Why it matters: IAM, NHI, and security teams need to treat AI agents as governed actors that can touch tools and data, because the control problem now sits at the point of action, not just the point of prompt.

Context

AI agents change the identity problem because they do more than generate text. Once a system can call tools, read files, and hit APIs, the security boundary shifts from model behaviour to governed action, which means access control, logging, and revocation become core controls rather than supporting features.

That is why open source security tooling matters in this category. The practical issue is not whether an LLM is clever enough, but whether the surrounding control plane can see what the agent touched, limit what it may touch, and keep those controls inside the organisation's own environment.

Key questions

Q: Where does AI security fail when agents have delegated tool access?

A: It fails when the organisation treats delegated tool use as ordinary application behaviour instead of privileged runtime action. An agent that can call tools, touch files, or reach internal services can turn a poisoned instruction into a real outcome. The control gap is not just model safety, but authority scope and runtime containment.

Q: Why do open source controls matter more for AI agents than for chatbots?

A: Agents create security decisions at runtime, not just text outputs. Open source controls matter because teams can inspect detection logic, extend policies, and keep enforcement close to their own infrastructure. That visibility is critical when prompt injection or tool misuse can turn a harmless-looking request into unauthorised access.

Q: What are the signs that MCP governance is missing from an AI programme?

A: Look for ad hoc connectors, duplicated credentials, unclear ownership of tool access, and limited audit evidence for agent actions. Those signals usually mean the organisation has treated MCP as a plumbing problem rather than an access-control problem. When that happens, revocation and review become slow or impossible.

Q: How should teams compare runtime guardrails with governed access control for agents?

A: Runtime guardrails shape what the model says or accepts, but governed access control decides what the agent can actually do. Both are useful, but they solve different problems. If the agent can still reach sensitive tools unchecked, output filtering alone will not prevent data exposure or unintended actions.

Technical breakdown

Why tool-using AI agents need governed access

A chatbot answers questions, but an agent can take action through tools, files, and APIs. That changes the security model from content moderation to authorisation and audit. Once a model can invoke an MCP server or other connector, the question becomes whether the request is authenticated, whether the action is within scope, and whether the resulting activity is logged in a way security teams can review. In practice, the dangerous part is not only malicious prompts but uncontrolled tool reach. Practical implication: govern the agent's actions at the access layer, not only at the prompt layer.

Practical implication: govern the agent's actions at the access layer, not only at the prompt layer.

What open source changes in AI security operations

Open source security tools shift AI defence from opaque inspection to inspectable policy logic. That matters because prompt injection, jailbreaks, and data leakage techniques evolve too quickly for closed detection logic to remain sufficient on its own. When the probes, validators, and guardrails are visible, teams can review what is being checked, extend coverage when new abuse patterns appear, and keep the security workflow close to their own pipelines. Self-hosting also matters because prompts, credentials, and logs can remain under organisational control instead of passing through a third-party service boundary. Practical implication: choose controls you can inspect, tune, and keep local to your environment.

Practical implication: choose controls you can inspect, tune, and keep local to your environment.

Why MCP governance is becoming the identity problem

MCP is important here because it standardises how agents reach tools and data sources, which means it also standardises the attack surface. If MCP servers are created ad hoc, the environment accumulates ungoverned connectors, reused credentials, and unclear ownership of the actions an agent can perform. A gateway model changes that by inserting a policy decision point before each request reaches a tool. That is identity work, not just application plumbing, because it binds access to identity, enforces least privilege, and preserves evidence for review. Practical implication: treat connector governance as part of your identity architecture.

Practical implication: treat connector governance as part of your identity architecture.

Threat narrative

Attacker objective: The objective is to make the agent perform authorised-looking actions that expand access or leak data without a clear governance trail.

1. Entry occurs when a user or agent reaches a tool through an unvetted prompt, connector, or MCP server with insufficient request controls.
2. Credential or action abuse follows when the agent is allowed to call files, APIs, or downstream tools beyond the intended scope of the request.
3. Impact is realised when those unchecked actions expose data, trigger unintended operations, or create a persistent governance blind spot around what the agent touched.

Breaches seen in the wild

• Gemini AI Breach — Google Calendar Prompt Injection: Gemini AI assistant prompt injection attack leaks sensitive Google Calendar data.
• Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Open source has become a governance mechanism, not just a licensing choice: In agentic environments, the decisive issue is whether teams can inspect policy logic, connector behaviour, and audit output. Closed tools may provide control, but they do not always make the control legible to the security team. The market is moving toward tools that can be verified, extended, and self-hosted because identity governance for agents depends on visible enforcement.

Agent governance now sits at the point of action: The old security question was whether the model generated a harmful answer. The new one is whether the agent can reach the wrong tool with the right-looking request. That is a material shift for IAM and NHI programmes because authorisation, logging, and revocation must happen before an action is executed, not after a response is produced.

Unvetted MCP sprawl creates identity debt: Each unmanaged connector adds another place where credentials, tool scope, and ownership can drift apart. The problem is not merely exposure, but the accumulation of access paths that no programme can confidently certify. Practitioners should read this as a sign that connector inventories now belong in the same governance conversation as service accounts and API keys.

Agentic security is converging on defence-in-depth across build, runtime, and governance: The article's tool set maps to three distinct layers: pre-deployment testing, runtime validation, and access control. That pattern is important because no single control can cover prompt injection, tool misuse, and data exfiltration together. The field is maturing toward layered assurance, and practitioners should expect programmes to blend red teaming, guardrails, and governed gateways.

MCP governance is the named control gap hiding inside agent adoption: The concept is not just 'AI security', it is governed access to model-connected tools. Once agents can reach external systems, the relevant control is whether each connector is approved, scoped, logged, and revocable. Teams that ignore this gap will end up reviewing agent behaviour long after the access decision has already happened.

From our research library:

• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.
• Read next: Agentic AI Security Guide

What this signals

MCP governance debt: The more agents are connected to tools through unvetted MCP servers, the faster access paths outgrow manual review. Security teams should expect connector sprawl to behave like credential sprawl, with ownership gaps appearing well before a breach does.

Open source control planes will keep gaining traction where organisations need to inspect policy logic, self-host sensitive traffic, and adapt quickly to new prompt injection techniques. That means agent governance will increasingly look like a lifecycle problem: approve the connector, scope the access, log the action, and revoke it cleanly when the use case ends.

For practitioners

• Map every agent connector Inventory every MCP server, API connector, and tool path that an agent can reach. Assign an owner, a purpose, and a revocation path so the access surface is visible before deployment.
• Insert a policy gate before tool use Require authentication, authorisation, and logging before any agent request reaches a tool or data source. Use the gateway as the enforcement point, not the model prompt as the control point.
• Separate red teaming from runtime enforcement Use pre-deployment probing to find prompt injection and leakage paths, then keep runtime validators and access controls in place after release. Testing alone does not stop post-launch misuse.
• Treat self-hosting as a control decision Keep prompts, credentials, and audit logs inside your own environment where regulatory scope or data sensitivity demands it. Self-hosting is most valuable when the system touches regulated or high-trust workflows.

Key takeaways

• Open source AI security tooling is filling a governance gap that model-only controls cannot close for agentic systems.
• The critical control point is agent action, not just prompt content, because tools, files, and APIs extend the attack surface.
• Practitioners should treat MCP governance, auditability, and revocation as core identity controls for AI agents.

Key terms

• Agentic security: The practice of governing software actors that can choose actions, tools, and timing in production workflows. It extends identity, authorization, logging, and lifecycle control to agents so their behaviour is tied to a verifiable principal and a revocable permission set.
• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Tool Misuse: Tool misuse occurs when an agent uses an allowed integration in a way that exceeds its intended task, scope, or risk tolerance. The problem is often not access alone but the combination of valid credentials, broad permissions, and unbounded action sequencing.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.