Both frameworks expect evidence that controls operated continuously, not just that they were designed correctly. AI agents can change behaviour, permissions, or tool use between reviews, so the organisation needs day-by-day proof that effective access and system behaviour remained inside approved boundaries.
Why the Evidence Requirement Changes Once an AI Agent Can Act
SOC 2 Type 2 and PCI-DSS both care about whether controls actually operated over time, not whether a policy existed on paper. That matters more for AI agents because their permissions, prompts, tool access, and outputs can shift between review points. Evidence has to show the agent stayed inside approved behaviour, not just that the control design looked sound on the day of testing.
For agentic systems, the audit question is not simply “was access approved?” It is “did the same access remain bounded, monitored, and attributable while the agent was running?” That changes the evidentiary burden from static configuration proof to continuous operational proof, especially when the agent can invoke tools, consume secrets, or act under delegated authority.
In practice, this means logs, approvals, policy decisions, and runtime traces need to line up across the full operating period. If the evidence only captures initial provisioning or a single point-in-time permission review, it will not tell an auditor whether the agent later exceeded its intended scope, reused credentials, or performed actions that were never reviewed.
What Auditors Expect to See for Continuous Control Operation
Type 2 evidence is strongest when it demonstrates a repeatable chain from approval to execution to review. For AI agents, that chain should show who approved the agent, what it was allowed to do, what actions it actually took, and how exceptions were detected and handled. AI Agent Authorisation Guide is useful because it frames the access decision as task-scoped and action-scoped, which is the right unit for evidence.
PCI-DSS raises the bar when the agent can touch cardholder data systems or adjacent payment workflows. PCI DSS v4.0 places direct emphasis on least privilege and on managing system and application accounts that can log in interactively, so auditors will expect proof that an agent did not become a hidden human-like operator with standing access.
SOC 2 evidence is broader, but the same principle holds: you need records that show the control functioned throughout the review period. For an AI agent, that usually means a combination of access approval records, policy enforcement logs, command or tool invocation logs, and exception handling records that together prove the control was not merely designed well, but operated well.
Where AI Agents Create the Hardest Evidence Gaps
The hardest gap is drift. An agent may be deployed with one permission set, then later pick up a new connector, a broader token scope, or a human-approved exception that was never folded back into the formal control record. When that happens, the organisation may still have “evidence” of good governance, but not evidence that the runtime reality stayed aligned with it.
Another gap is attribution. If several operators, automated workflows, or delegated credentials can influence the agent, the record may show an action happened without showing why it happened, who authorised it, or whether it stayed within policy. AI Agent Observability, Audit and Incident Response Guide matters here because traceability is the difference between an explainable control and a fragile one.
PCI-DSS evidence also tends to expose secret handling weaknesses quickly. If an agent is using long-lived credentials or borrowed human credentials, the control may look compliant at provisioning time but fail the operational test later when those credentials are reused in ways the review never captured. That is why the evidence set must include lifecycle events, not just access state.
Risk and Threat Considerations
When auditors cannot see continuous evidence, they have to assume the control could have drifted, and that creates both compliance and security exposure. For AI agents, the risk is that a tool-enabled identity accumulates broader access or performs actions outside reviewable boundaries while the organisation still believes it is operating under approved controls.
Failure mechanism: The agent’s effective permissions, credentials, or tool access change after the control was last reviewed, but the organisation retains only point-in-time evidence. That leaves a gap between formal approval and actual runtime behaviour, which is where excessive access, misuse, or unauthorised actions can hide.
Impact: The organisation may fail an audit, lose confidence in its access controls, or miss a real abuse path until after the agent has already acted. In a payment environment, that can widen exposure to cardholder-data systems, weaken accountability, and force emergency remediation instead of orderly control evidence.
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 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and PCI DSS v4.0 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | AI agents need auditable runtime traces to prove controls operated continuously. |
| IA-5 — Authenticator Management | Agents often rely on credentials or tokens that must be tracked across the review period. | |
| AC-6 — Least Privilege | Type 2 and PCI evidence must show the agent stayed within approved access boundaries. | |
| Recommendation — Log agent approvals, tool calls, and exceptions so runtime behaviour can be reconstructed. Track, rotate, and revoke agent credentials to preserve continuous control evidence. Enforce least privilege so the agent cannot accumulate standing access between reviews. | ||
| PCI DSS v4.0 | 7 — Restrict access by business need-to-know | PCI evidence must show access stayed limited to business need throughout operation. |
| 8 — Identify users and authenticate access | Interactive or account-based agent access needs continuous authentication evidence. | |
| Recommendation — Prove the agent’s access remained restricted to the minimum required business need. Maintain authentication records that show which account or token the agent used at each step. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent identity and privilege drift are central to continuous evidence failures. |
| Recommendation — Constrain the agent’s privilege so runtime actions stay aligned with approved authority. | ||
Practitioner Guidance
What to verify: Treat the evidence pack as a runtime story, not a design artefact. Verify that approval records, policy decisions, tool-use logs, and access reviews all cover the same period and the same effective permissions.
What good looks like: The auditor can trace a specific agent from approved scope to observed activity to exception handling, with no unexplained permission expansion, no unlogged tool use, and no reliance on borrowed human credentials.
Decision rule: If you cannot prove the agent’s effective access stayed bounded day by day, treat the control as operationally incomplete even if the original approval was sound.
Practitioner takeaway: For AI agents, auditability depends less on whether access was authorised once and more on whether the organisation can prove the same boundaries held continuously while the agent was active.
Related resources from NHI Mgmt Group
- How should organizations approach the governance of AI agents?
- Why does payment card data create higher PCI DSS risk when it moves through AI copilots and autonomous agents?
- Why does evidence-based scoping matter for PCI DSS compliance in complex environments?
- Why does runtime evidence matter for FedRAMP, PCI DSS 4.0, and SOC 2?