How can organisations control risk when AI systems are given pentesting credentials?

Scope those credentials like any other non-human identity. Give the agent only the access needed for the test, log every action, and revoke credentials as soon as the session ends. If the system can explore live applications, its access should be time-bound, observable, and easy to terminate.

Why This Matters for Security Teams

When AI systems are granted pentesting credentials, the risk is no longer limited to what a human tester might intentionally do. The credential can be copied, overused, cached, or chained into other tools, which turns a bounded assessment into a broader trust problem. The governance question is therefore not just whether the test is authorised, but whether the credential is traceable, constrained, and revocable in the same way as any other non-human identity, consistent with the direction of the OWASP Non-Human Identity Top 10.

Security teams often focus on payload safety and overlook identity lifecycle controls. That creates blind spots around privilege scope, session duration, and post-test cleanup. If the AI can move beyond the original test target, the organisation needs to know whether that access was deliberately approved or merely inherited from a reusable secret. In practice, many security teams encounter credential sprawl only after a test account has already been reused, rather than through intentional control design.

How It Works in Practice

Control starts by treating the pentesting credential as a tightly governed non-human identity, not as a convenience token. The identity should be issued for a specific purpose, mapped to a defined test scope, and placed under a clear owner who can terminate it immediately. Where possible, organisations should prefer short-lived access over static secrets, and they should align the control set to identity assurance and lifecycle guidance in NIST SP 800-63 Digital Identity Guidelines and operational control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.

In practice, the strongest control pattern is to combine least privilege, session isolation, and continuous auditability. That means the AI should receive only the endpoints, roles, and time window needed for the test. If the platform supports it, the credential should be bound to the test run, not to the underlying agent indefinitely. Logs should capture who approved the run, what the AI accessed, what it changed, and when the session ended.

• Issue credentials per test, not per agent, so scope stays narrow.
• Use time-bound secrets or delegated tokens with automatic expiry.
• Separate read, write, and exploit-capable access where the environment allows it.
• Record actions at the session level so activity can be reviewed and attributed.
• Revoke access immediately after the test, even if the run completed normally.

Operationally, this fits the broader risk management approach in the NIST Cybersecurity Framework 2.0, especially where organisations need to identify assets, protect access paths, detect misuse, and respond quickly to abnormal behaviour. These controls tend to break down when credentials are shared across multiple agents or test environments because attribution, revocation, and blast-radius containment all become unreliable.

Common Variations and Edge Cases

Tighter credential controls often increase operational overhead, requiring organisations to balance test realism against speed, automation, and analyst convenience. That tradeoff is real, especially in red team exercises, continuous assurance pipelines, and environments where the AI must interact with live applications rather than isolated labs.

Current guidance suggests there is no universal standard for how much autonomy a pentesting agent should have once it is authenticated. Some teams will allow read-only discovery but require human approval for any action that modifies state. Others will permit limited exploitation in a controlled window, provided the session is monitored and kill-switch mechanisms are tested in advance. The right pattern depends on whether the objective is vulnerability discovery, controlled validation, or adversarial simulation.

Edge cases matter when the credential is tied to shared infrastructure, third-party platforms, or production-like data. In those settings, even a short-lived token can expose sensitive systems if logging is weak or if the AI can pivot through trusted integrations. Identity-bound controls should therefore be paired with explicit environment segmentation, approved toolchains, and clear evidence retention rules. Where organisations handle personal data or regulated systems, the identity assurance baseline from NIST remains relevant, but the final risk decision should reflect the specific test objective and the tolerance for live-system interaction.

Related resources from NHI Mgmt Group

• How should organisations control access to frontier AI systems without creating surveillance risk?
• How do organisations control the risk of AI systems performing offensive workflows?
• Why do AI systems make NHI risk harder to control?
• Why do chat-based AI systems create new identity risk for organisations?