Every framework requires an identifiable actor. Contractor BYOD and AI agents are what breaks it.
AI compliance software, including GRC platforms like Vanta, Drata, and Secureframe, tracks compliance obligations, and some now flag or block an agent's action inside the SaaS platforms they monitor. But none of them sit between a device and a production host deciding what a shell command does, and that's the question every framework below is actually written to make answerable: whose hands were on this command?
Every framework requires an actor. None of them names the agent as one
None of the rules that govern privileged execution names an AI agent as its own category of actor. Each one instead requires the actor behind it to be identifiable—"user," "individual," "subject"—categories written before agents existed.
NIST SP 800-53 Rev. 5 AU-3 requires audit records to include the "identity of any individuals, subjects, or objects/entities associated with the event." AU-10 goes further: non-repudiation requires irrefutable evidence that "an individual (or process acting on behalf of an individual) has performed" the action—the control already contemplates a process acting for a human. It just assumed that process was a script, not an LLM.
The rest of the stack asks the same question
PCI DSS v4.0.1 tightens the same screw from three directions: Req. 10.2.2 requires per-event user identification in audit logs, Req. 8.2.2 restricts shared and generic accounts to documented, managed exceptions, and Req. 8.6 treats non-human identity as its own class. The HIPAA Security Rule §164.312(a)(2)(i) requires a unique identifier for tracking user identity. NYDFS 23 NYCRR 500.7 requires every covered entity to limit privileged accounts to what the role requires, and Class A companies to run a privileged access management solution—both in force since 2025-05-01. The EU AI Act's Annex III high-risk deadline has shifted to 2027-12-02 under the Digital Omnibus, and Art. 12(1)'s automatic event-logging requirement and deployers' duty to retain them for at least six months under Art. 26(6) arrive with it—assuming an infrastructure-operations agent running shell commands on your own production hosts even counts as an Annex III high-risk system, which has no official guidance either way. What binds today is Art. 50 transparency and Art. 4 AI literacy, and neither reaches actor attribution.
Across NIST AU-3, PCI 10.2.2, and HIPAA §164.312(a)(2)(i), the pattern holds: "actor recorded per execution" is required today. NIST AU-10 and NYDFS 500.7 ask for something more specific: an attested actor, established by a provable origin—like a privileged access management solution—rather than a value the system reports about itself. The EU AI Act's Art. 12 and Art. 26(6), when they arrive in 2027, are about retaining and reconstructing the record, not about naming the actor. And "actor is a policy input"—gating differently because the actor is human or AI—is required by none of them. That's a product decision, not a compliance one. But it doesn't matter which bar your auditor is checking against if you can't answer the first question.
Where contractor BYOD breaks the chain
Here's the exact combination that trips this up. A contractor logs into their own account—correctly provisioned, tied to their name—from a personal laptop, and kicks off automation that spins up an agent against a production database. The audit log names an actor: the contractor. What actually ran the command was the agent. Every framework above assumes the account and the actor are the same, or at most that a predictable script is acting on someone's behalf—not an agent choosing its own commands in the moment. So the account being linked to a person doesn't mean the actor field is empty. It means it's wrong. The device isn't managed, either: contractors on developer forums describe being issued slower, older equipment than the full-time staff they work alongside on the same production systems, and BYOD is often explicitly disallowed on paper even when the issued hardware is what's actually inadequate—so the personal laptop shows up anyway. The agent isn't named anywhere in the log. It just says the contractor did it.
This isn't a contractor-specific failure so much as contractors and BYOD are where it shows up first: personal devices and unattended automation are exactly where a contractor's own account starts running things the contractor never typed, and an AI agent riding on top of that access is invisible by construction, not by malice. It's not a fringe scenario, either: 82% of enterprises report unknown AI agents already running somewhere in their environment, and 65% have had an AI-agent-related incident in the past year—only 21% have formal decommissioning.
Where the record has to start
GRC platforms sit outside the execution path in exactly this sense: whatever they flag inside SaaS tools, they don't sit between the device and the host deciding what runs. When a session does go through Alpacon, that's the layer it sits in: a Work Session is opened with an identity, a declared intent, and a scope ceiling, so the record names a person and a purpose, not just an account. On the exec lane, a command an agent runs that the AI judges off-purpose for the session's declared work is routed to a human instead of auto-approved.
If you're evaluating "AI compliance software," ask the vendor a narrower question than the search bar suggests: not "do you track compliance," but "when a contractor's agent runs a command, whose name lands on the record—and is it the truth?"
