The recent FBI breach attributed to ShinyHunters should concern every CISO, but not because the attackers demonstrated some extraordinary new capability. In many ways, the opposite is true. The vulnerability reportedly involved Oracle PeopleSoft. Oracle had already disclosed it, assigned it a critical severity rating of 9.8 out of 10, and issued a patch. The FBI later said its review determined that a contractor failed to implement a security patch intended to secure the platform.
That makes this breach important for a different reason. It exposes one of the oldest and most persistent problems in cybersecurity. We continue to confuse trust with verification.
Virtually every large organization depends on outside providers to operate some portion of its infrastructure. That is unavoidable. What is avoidable is assuming that outsourcing the work also outsources accountability. If a service provider is responsible for patching a critical system, the organization still needs independent evidence that the patch was actually applied.
A ticket marked complete is not enough. A contractual service level is not enough. For critical vulnerabilities, enterprises need to verify the actual state of the environment. Is the vulnerable software still running? Is the exposed endpoint reachable? Was the correct mitigation deployed? Can the known exploit still succeed?
The lesson is not that organizations should stop using contractors. It is that cybersecurity controls cannot depend on assumptions about what another organization did.
We have exactly the same problem with identity. For decades, authentication has operated on another set of assumptions. Someone knows the password, so perhaps it is the employee. Someone enters the six-digit code, so perhaps it is the employee. Someone taps approve on an authenticator application, so perhaps it is the employee.
Attackers have learned to exploit every weak assumption in that process. Stolen credentials, real time phishing, MFA fatigue, help desk impersonation and session hijacking work because many authentication systems still accept evidence that can be transferred from one person to another. Attackers increasingly do not need to break through the network. They can simply convince the network that they are someone who belongs there.
Passkeys are an important improvement, but enterprises should be careful about treating broad passkey deployment as synonymous with high-assurance authentication. If employees are allowed to register essentially any consumer phone or personal device, the enterprise may have limited knowledge of that device’s security state. AAGUID restrictions can identify and permit specific authenticator models or providers, but they become much less useful when an organization intends to support a broad universe of consumer devices. Microsoft itself provides controls for restricting passkeys by AAGUID and warns that without attestation it cannot guarantee whether a passkey is synced or device bound.
There is another frequently overlooked issue. FIDO2 signature counters can help identify certain forms of credential cloning or abnormal authenticator behavior, but the FIDO specification allows counter support to be optional in order to support shared passkeys and consumer devices. A phone for example can legitimately return a counter value of zero to indicate that counters are not supported. That means an enterprise SSO platform cannot simply assume that every passkey it accepts will provide an enforceable counter. And an ignored counter allows passkeys to be relayed and replayed.
The result is that the security of a passkey deployment depends heavily on how tightly the authenticator population is controlled. A passkey held in dedicated, attested hardware is fundamentally different from a policy that says virtually any consumer device can become the enterprise credential holder. Once the latter approach is adopted, some of the strongest controls become difficult to enforce consistently.
For high-assurance access, dedicated biometric hardware can therefore go further by requiring a known physical authenticator, a cryptographic credential bound to the legitimate domain, physical proximity and a live biometric match from the authorized human. The important principle is not any particular product. It is eliminating transferable proof of identity and reducing uncertainty about the device that is asserting it.
AI agents make this considerably more urgent. We are introducing a new class of identity into enterprise networks, and these agents will increasingly be able to access databases, modify accounts, provision infrastructure, deploy software and potentially initiate consequential transactions.
An AI agent can possess a perfectly valid machine identity and still perform an action that no responsible human intended. Giving an agent credentials therefore answers only one question: which agent is this? It does not answer the more important question: did an authorized human actually approve this action?
Enterprises need to separate machine authentication from human authorization. An AI agent should have its own cryptographic identity, narrowly defined permissions and a limited blast radius. But for consequential actions, there should also be an independent human authorization gate.
That authorization should not simply consist of clicking ‘approve’ on a screen. As AI makes impersonation, phishing and social engineering more convincing, relying on weak approval mechanisms to control increasingly powerful autonomous systems would repeat the mistakes we made with legacy MFA.
For high-consequence actions, enterprises should be able to establish cryptographically that a specific authorized human was physically present and deliberately approved the transaction. Dedicated hardware biometric authorization offers one way to create that hard boundary. The agent can request the action, but it cannot approve itself.
There is a common thread connecting an uninstalled security patch, a weakly controlled passkey, a stolen credential and an autonomous AI agent. In every case, the dangerous assumption is the same. We thought something was true, so the system proceeded as though it had been proven.
The future of cybersecurity is not more trust. It is absolute proof.
Join our LinkedIn group Information Security Community!
