Protect AI vs Akto: what AI security governance actually changes

At a glance

What this is: This compares model security and agent-centric AI security, showing that governance now has to account for models, MCPs, AI agents, and runtime behavior together.

Why it matters: It matters because IAM, IGA, PAM, and security teams need to decide whether their current controls can govern AI agents and connected tools, not just models and applications.

👉 Read Akto's comparison of Protect AI and agentic AI security

Context

AI security is no longer just a model-scanning problem. Once AI systems can discover tools, call APIs, and operate across workflows, the control question shifts to identity, privilege, and runtime accountability across the full execution path.

This article uses Protect AI as the comparison point, but the real issue is broader: which security model can actually govern AI agents, MCP-connected tools, and the credentials they rely on. For identity teams, that means treating agent behaviour, not just model content, as part of the security surface.

Key questions

Q: How should security teams govern AI agents that choose tools at runtime?

A: Security teams should treat runtime tool choice as a governed access event, not a normal application call. That means task-scoped credentials, explicit approval boundaries for sensitive actions, and logs that record both the tool selected and the identity used. If the agent can change its plan, the control model must be able to change with it.

Q: Why do AI agents complicate traditional IAM reviews?

A: Traditional IAM review assumes identities have human lifecycle events such as hire, role change, or offboarding. AI agents do not follow that pattern, so access can drift silently unless teams build continuous entitlement governance. Without that shift, reviews become retrospective paperwork instead of active risk reduction.

Q: What breaks when AI security stops at model scanning?

A: Model scanning helps identify tampering and unsafe dependencies before deployment, but it does not address runtime misuse. Once the system is live, prompt injection, unsafe tool use, and manipulated responses can still drive harmful behaviour. Without runtime controls, the most important security decisions happen after the pre-check has already passed.

Q: How do security teams know runtime AI guardrails are actually working?

A: Look for blocked poisoned inputs, flagged anomalous outputs, and traceable enforcement before responses reach users or downstream systems. If controls only inspect prompts or only inspect outputs, they leave a gap that attackers can exploit through manipulated data sources or tool responses.

Technical breakdown

Model security vs agent identity security

Model security focuses on what enters the model lifecycle: training data quality, harmful code, backdoors, and pre-deployment scanning. Agent identity security starts later in the chain, where an AI agent or workflow can select tools, request data, and execute actions against live systems. Those are different control planes. A model can be clean while the agent using it still has unsafe access, excessive tool reach, or uncontrolled runtime paths. That is why model assurance does not replace identity governance for AI systems.

Practical implication: separate model risk controls from agent access controls and do not treat one as coverage for the other.

MCP security and runtime authorisation

MCP connects AI agents to tools and data sources, which makes it an identity and authorisation problem as much as an integration problem. Once an agent can call a connector, the security issue becomes whether that invocation is permitted, logged, limited, and reversible. Runtime monitoring matters because the risky event is not only the tool being available, but the agent choosing to use it in a live session. That shifts emphasis from static allowlists to continuous authorisation and postured guardrails.

Practical implication: inventory every MCP connector and bind it to explicit policy, logging, and least-privilege scope.

Guardrails, discovery, and shadow AI

Discovery is the starting point because undiscovered agents and endpoints cannot be governed. AI guardrails then define what those discovered systems are allowed to do, including masking sensitive data, blocking unsafe actions, and constraining blast radius. This is especially important where shadow AI exists, because unmanaged agents often arrive through copilots, embedded automation, or internal experiments that bypass formal review. The security failure is not just exposure, but untracked execution authority.

Practical implication: build continuous discovery for AI agents and tie it directly to policy enforcement and access review.

NHI Mgmt Group analysis

AI model security and AI agent governance are not interchangeable control problems. Model scanning can reduce the risk of poisoned inputs, vulnerable artifacts, and unsafe deployment content, but it does not govern what an agent does after deployment. Once the actor can take independent actions across tools and APIs, the relevant question becomes privilege, delegation, and runtime accountability. Practitioners should treat model assurance as one layer, not the operating control for AI behaviour.

Shadow AI creates the same governance blind spot that unmanaged NHIs created in cloud infrastructure. If an AI agent or MCP endpoint is undiscovered, there is no recertification, no ownership mapping, and no policy boundary worth trusting. The named concept here is runtime governance gap: a system can appear controlled at design time while remaining operationally ungoverned at execution time. That gap is now central to agentic AI security.

Least privilege for AI agents must be expressed as runtime scope, not just provisioning intent. Static permissioning assumes the system will stay inside a predictable workflow, but agentic execution can expand tool use, data reach, and task chaining within a session. That means old identity assumptions about stable access patterns are already under pressure. The practitioners who will cope best are the ones who separate policy definition from session-time enforcement.

Visibility without enforcement is only an inventory exercise. Discovery, dashboards, and risk scoring help teams understand their AI attack surface, but they do not stop unsafe delegation by themselves. The field is moving toward continuous control of agents, connectors, and credentials because AI governance failures now happen at runtime, not only during build or deployment. Security teams should expect identity governance to become a live operational discipline for AI systems.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That confidence gap is why the Ultimate Guide to NHIs , 2025 Outlook and Predictions remains relevant for teams building AI agent and workload identity controls.

What this signals

Runtime governance gap: teams should expect AI security to move from pre-deployment validation toward continuous control of agents, connectors, and delegated credentials. Once runtime behaviour matters, identity and access reviews have to reflect execution paths, not just application ownership.

The governance pattern is familiar to identity teams that have already dealt with shadow IT and unmanaged service accounts. AI systems now create the same visibility problem at higher speed, which means discovery, ownership, and revocation need to be linked in the same operating motion.

With 1 in 4 organisations already investing in dedicated NHI security capabilities, per The State of Non-Human Identity Security, the market signal is clear: AI agents are being pulled into the same governance conversation as machine identities and privileged automation.

For practitioners

• Map AI agents to their actual credentials and tool reach Identify every agent, MCP connector, and API endpoint in use, then record which credentials, scopes, and data sources each one can touch. If ownership is unclear, the access is already outside governance.
• Separate model review from runtime access review Do not sign off on an AI system only because the model passed pre-deployment testing. Require a distinct review for live permissions, delegation paths, logging, and revocation procedures.
• Enforce least privilege at the connector layer Use policy to constrain which tools an agent can invoke, which data it can retrieve, and which actions require additional approval. Review those policies whenever the workflow changes.
• Continuously discover shadow AI before it normalises Run recurring discovery across endpoints, cloud services, and AI gateways so unmanaged agents do not accumulate hidden access. Tie the results to access reviews and exception handling.
• Test runtime guardrails against prompt injection and tool misuse Validate whether the agent can be pushed into unsafe tool calls, overbroad data access, or unapproved action chains. Treat those tests as operational controls, not theoretical research.

Key takeaways

• AI model security does not cover the full identity and access risk created by AI agents and MCP-connected tools.
• The practical control problem is runtime privilege, discovery, and delegation, not only model integrity or pre-deployment testing.
• Identity teams should govern AI systems as live actors with credentials, scopes, and revocation requirements, not as static software features.

Key terms

• Agentic AI Security: Agentic AI security is the discipline of securing autonomous AI systems that can take actions, use tools, and chain decisions without direct human approval at each step. It covers identity and access management for AI agents, prompt injection defence, tool call governance, credential scoping, and runtime monitoring. As agentic systems acquire real-world authority — API access, file writes, workflow triggers — the security model must treat them as non-human identities with explicit lifecycle controls, not trusted processes.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Runtime Governance: Runtime governance is the set of controls that verify what a system or agent is actually doing after deployment. It combines monitoring, authorization checks, and access validation so teams can detect drift, misuse, or excessive privilege in motion rather than assuming build-time policy still holds.

What's in the full article

Akto's full blog post covers the operational detail this post intentionally leaves for the source:

• Side-by-side product feature descriptions for Protect AI and Akto across discovery, runtime monitoring, and guardrails
• More granular discussion of AI agent and MCP discovery coverage across endpoints, connectors, and infrastructure
• Tool-level comparisons for model scanning, red teaming, and runtime protection workflows
• Implementation-oriented product positioning for teams evaluating AI security platforms

👉 Akto's full post covers the product feature breakdown and side-by-side capability comparison.

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 identity security across human and non-human systems, it is worth exploring.