AI security testing tools need identity-aware controls for agents and MCP

At a glance

What this is: This is a practitioner guide to AI security testing tools, with a central finding that effective testing must cover models, APIs, agents, and MCP workflows across the AI lifecycle.

Why it matters: It matters because IAM, PAM, and AI security teams now need evidence that agentic systems cannot abuse delegated access, expose secrets, or act outside policy boundaries.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read Akto's guide to the best AI security testing tools for agents and MCP

Context

AI security testing is the control layer that checks whether models, APIs, agents, and workflows behave safely under adversarial pressure. In the primary keyword area, the gap is not just model robustness, but whether identity, delegation, and tool access are governed as part of the security test surface.

Traditional application testing misses issues such as prompt injection, tool misuse, data poisoning, model inversion, and shadow AI endpoints. For IAM and NHI programmes, that means an AI system can look compliant at the interface level while still carrying delegated access that is too broad, too persistent, or too difficult to audit.

Akto's article frames the tooling landscape, but the deeper governance question is how organisations prove that an AI system cannot use agent-to-tool paths to exceed policy. That starting position is typical for current AI programmes, which often test the model before they test the identity and access layer around it.

Key questions

Q: How should security teams test AI agents that can call tools and APIs?

A: They should test the agent's actual execution paths, not just its text responses. That means covering tool calls, protocol handling, approvals, and state transitions with adversarial scenarios that mirror real misuse. If the test cannot reach the access point where the agent acts, it does not meaningfully assess the security risk.

Q: Why do MCP-based agents create new access control risks for IAM teams?

A: Because they turn a model from a text generator into a delegated actor that can reach real systems. Once the agent can send mail, query data, or execute commands, a broad token or static rule can expose far more access than the originating task requires.

Q: What breaks when AI security testing ignores undocumented endpoints?

A: Coverage fails at the exact point where shadow AI often lives. If an agent endpoint is not inventoried, it will not be tested, monitored, or governed consistently. That creates a blind spot where an attacker can abuse a live path without triggering the controls built for known systems.

Q: What should organisations do when AI testing finds unsafe tool behaviour?

A: Treat the result as an access-control issue, not only a model defect. Organisations should narrow scopes, shorten token lifetimes, add approval checks for high-risk actions, and remove unused connectors. The goal is to make the same unsafe action impossible to repeat after remediation.

Technical breakdown

How AI security testing covers model, pipeline, and runtime risk

AI security testing is broader than validating model output accuracy. It needs to examine the model layer, where weights and decision boundaries can be manipulated, and the pipeline layer, where training data, fine-tuning inputs, and deployment artefacts can be poisoned or altered. It also needs runtime testing for prompt injection, jailbreaks, extraction, and unauthorized tool use. In agentic systems, the attack surface includes orchestration logic, connectors, and MCP-style tool paths, not just the LLM itself. Practical implication: test the full AI execution path, not only the model endpoint.

Practical implication: extend testing to data, orchestration, and tool access so agent behaviour is validated end to end.

Why prompt injection and tool misuse are identity problems

Prompt injection becomes an identity issue when an agent can turn untrusted instructions into action through delegated permissions. The risk is not only that the model says the wrong thing, but that it can call tools, retrieve records, or trigger workflows with the authority it has been given. That is why AI security testing must inspect authorization boundaries, not just content filtering. In practice, the security question is whether a prompt can induce action outside intended scope. Practical implication: bind prompts, tools, and permissions to explicit policy checks before execution.

Practical implication: treat tool invocation as an authorization event and verify policy before the agent acts.

Model supply chain auditing is necessary but not sufficient

AI supply chain tools help trace dependencies, datasets, packages, and third-party integrations, which is essential for spotting hidden backdoors or unsafe components. But supply chain visibility alone does not catch runtime abuse, especially when an agent discovers undocumented endpoints or uses permitted tools in unintended ways. This creates a gap between build-time assurance and live operational control. The real control objective is continuous assurance across the AI lifecycle, from ingestion to deployment to monitoring. Practical implication: pair supply chain auditing with continuous runtime monitoring and adversarial testing.

Practical implication: combine build-time visibility with live controls so hidden dependency risk does not become runtime abuse.

Threat narrative

Attacker objective: The attacker aims to make an AI agent perform unauthorized actions or reveal sensitive data while appearing to operate within normal system behaviour.

1. Entry occurs through prompt injection, malicious instructions, poisoned data, or exposure of shadow AI and undocumented agent endpoints.
2. Escalation happens when the agent converts those inputs into tool calls, API requests, or workflow actions under delegated authority.
3. Impact is reached when the system exposes sensitive data, performs unsafe actions, or extends access beyond the intended policy boundary.

NHI Mgmt Group analysis

AI security testing is now an identity governance problem, not just a model quality problem. Once an agent can call tools, retrieve data, or trigger workflows, the meaningful security question becomes who or what is authorised to act. That shifts testing from content validation to delegated access validation. Organisations should therefore test AI behaviour as part of IAM and NHI governance, not as a standalone model exercise.

Shadow AI expands the attack surface faster than traditional assurance can follow. Akto's emphasis on undocumented endpoints reflects a broader governance issue: if teams cannot inventory agents, they cannot test them consistently. This is the same control problem seen in unmanaged non-human identities, where undiscovered credentials and service accounts bypass normal review. The practical conclusion is that discovery must precede policy.

Agentic AI creates a new form of policy drift, which we can call AI governance debt. Each new connector, model update, or workflow automation can widen access without a parallel control update. That debt accumulates until testing becomes a retrospective exercise rather than a preventive one. Security leaders should treat policy drift as a measurable operational risk, especially where MCP-style tool access is involved.

Continuous testing is only valuable if it is paired with runtime enforcement. A red-team finding that is not converted into access restrictions, alerting, or blocking logic becomes documentation rather than control. For AI systems, the governance bar is whether a tested weakness can still be exploited in production after the next prompt, model update, or connector change. Practitioners should demand closed-loop remediation.

What this signals

AI governance debt: the control gap grows each time teams add a model, connector, or autonomous workflow without updating access policy and test coverage. For practitioners, the signal is simple: if discovery, authorization, and monitoring do not move together, AI risk will outpace governance no matter how many point tools are deployed.

Security teams should expect AI security testing to converge with NHI governance, especially where MCP-style tool paths and delegated credentials are involved. That convergence will force IAM, PAM, and AI security leads to share ownership for lifecycle controls, because the failure mode is no longer just unsafe output. It is unsafe action with valid access.

The operational priority is closed-loop control: discovery feeds policy, policy feeds testing, and testing feeds enforcement. Without that loop, a successful red-team result only documents exposure. With it, security teams can prove that agent behaviour stays inside approved boundaries even as workflows, models, and integrations change.

For practitioners

• Inventory every AI endpoint and agent connection Build a live register of LLM APIs, agent endpoints, MCP servers, and undocumented shadow interfaces before you attempt coverage testing. A test plan that misses hidden paths will leave the highest-risk routes unexamined. Use discovery outputs to set ownership and review cadence.
• Test authorisation at the tool layer Simulate prompt injection, tool misuse, and instruction hijacking against the exact actions an agent can take. Validate that every tool call passes policy checks, least privilege rules, and explicit approval thresholds where needed. Do not accept model-level safety as proof of operational safety.
• Link AI red-teaming to IAM and PAM controls Translate every successful attack simulation into a control change such as tighter scopes, shorter-lived tokens, stronger approval gates, or revocation of unused access. If the attack path depends on standing credentials, the remediation belongs in identity governance, not only in the AI stack.
• Monitor for behaviour that exceeds intended scope Track data access, tool invocation patterns, and unexpected workflow execution so you can identify when an agent crosses its approved boundary. Use those signals to trigger containment before sensitive records are exposed or actions are completed outside policy.

Key takeaways

• AI security testing now has to validate whether agents can act safely, not merely whether models respond correctly.
• The evidence base is clear that agentic systems already exceed intended scope often enough to justify governance as a live control problem.
• The control gap closes when discovery, authorization, and runtime enforcement are tested together across the full AI lifecycle.

Key terms

• AI-driven security testing: AI-driven security testing uses automated analysis to discover vulnerabilities earlier in the software lifecycle. The practical value is not just speed, but earlier feedback while code, ownership, and context are still visible. It becomes useful when teams can repeat it continuously without creating extra operational friction.
• 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.
• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.

What's in the full article

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

• Step-by-step comparisons of AI security testing tool categories, including where each fits in development and runtime.
• Vendor-by-vendor examples of adversarial attack libraries, red-teaming platforms, and monitoring tools for AI workflows.
• Operational guidance on integrating AI testing into CI/CD, SOC workflows, and governance reporting.
• Detailed capability descriptions for MCP workflows, agent endpoints, and AI-to-API monitoring.

👉 Akto's full post covers tool categories, testing workflows, and deployment guidance for AI systems.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps practitioners connect identity controls to the broader security programmes that govern autonomous systems and access.