An evaluation designed to reveal what an agent can do now that it could not reliably do before. Unlike regression testing, which protects existing behaviour, capability evaluation explores the frontier of performance and helps teams decide whether a new workflow is ready for productisation.
Expanded Definition
Capability eval is a forward-looking assessment used to determine whether an agent, model, or automated workflow can reliably perform a task at a level sufficient for controlled deployment. It is different from regression testing, which checks whether known behaviour still works after a change. A capability eval asks a broader question: what new actions, reasoning patterns, or tool-use sequences has the system become capable of, and under what conditions does that capability hold?
In agentic AI security, this matters because new capability can mean new operational value, but it can also create new exposure if the system can now reach tools, data, or side effects that were previously out of scope. Definitions vary across vendors, and no single standard governs capability evals yet, so the term is often used differently across AI labs, product teams, and governance functions. NHI Management Group treats the term as a practical readiness gate for controlled experimentation, not as a substitute for safety validation or policy review. The most common misapplication is treating a capability eval as proof of safe deployment, which occurs when teams measure raw task success without testing for boundary violations, prompt sensitivity, or tool misuse.
Examples and Use Cases
Implementing capability eval rigorously often introduces additional test design and review overhead, requiring organisations to weigh faster model release cycles against the cost of deeper validation.
- An agent that previously summarized documents is re-evaluated to see whether it can now draft and send emails through a connected tool, using the task boundaries described in NIST Cybersecurity Framework 2.0 as a governance anchor for risk handling.
- A support workflow is tested for whether an LLM plus tools can complete a refund action end-to-end, including whether it respects approval steps and does not exceed its intended authority.
- An NHI team evaluates whether a new service account or token path enables an agent to access previously unavailable APIs, especially where secrets, certificates, or scoped credentials expand the blast radius.
- A red-team style exercise checks whether a model can now follow multi-step instructions that lead to unintended data disclosure, even when the prompts are different from those used in earlier tests.
- A product team validates whether an agentic assistant can independently retrieve, transform, and submit information to a downstream system before deciding if the workflow is ready for limited production rollout.
Why It Matters for Security Teams
Security teams need capability evals because the critical question is not only whether an agent works, but whether it can do more than expected once it is connected to real systems. In practice, the jump from “can answer questions” to “can act” is where governance, IAM, PAM, and NHI concerns begin to converge. If an agent can invoke tools, use secrets, or chain actions across systems, the organisation needs to understand the new control surface before the workflow is exposed broadly. That makes capability evals especially relevant to least privilege design, approval workflows, and containment boundaries.
The broader governance lens from NIST Cybersecurity Framework 2.0 helps teams translate capability growth into risk ownership, while identity-focused controls help determine whether the agent’s access still matches its intended role. For autonomous systems, capability gains can also alter the trust assumptions around non-human identities, because a newly capable agent may require tighter credential scope, stronger monitoring, or a revised kill switch. Organisations typically encounter the real impact only after an agent completes an unintended action or accesses a system it was never meant to reach, at which point capability eval becomes operationally unavoidable to address.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | CSF 2.0 frames risk management for emerging system capabilities. |
| NIST AI RMF | MAP | AI RMF maps system context and intended use, which capability eval depends on. |
| NIST AI 600-1 | The GenAI profile supports measuring and governing model behaviour in deployment contexts. | |
| OWASP Agentic AI Top 10 | Agentic AI guidance highlights tool abuse and unsafe autonomy risks exposed by new capabilities. | |
| OWASP Non-Human Identity Top 10 | NHI guidance applies when new agent capability changes token, secret, or service identity exposure. |
Assess generative system capability changes against documented use cases and controls before production.
Related resources from NHI Mgmt Group
- How do organisations know if their AI eval rubric is actually useful?
- How can teams tell whether a new platform capability is changing their risk posture?
- How should organisations reduce SaaS spend without losing business capability?
- Why do passwordless programmes still need password reset capability?
