Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Approval works at the tool layer and it works well. A platform is assessed, terms are reviewed, a data processing agreement is signed, the tool enters the register, and named identities are entitled to it. Everything about that maps cleanly. ‍ Then somebody uses the approved platform to assemble an agent that acts on their behalf, with its own reach and its own credentials. The approval covered the application.

Three reads from surfaces most organizations already own produce a usable AI usage register in a morning. Entitlement, from the identity provider, showing who is licensed for what. Activity, from network or gateway logs, showing who reached which destination and how much. Identity, from the directory, showing who those people are and which scopes they sit in. ‍ The register answers more questions than people expect.

External threat models estimate how often somebody gets in and what they reach afterward. The susceptibility term does most of the work, weighing what an attacker can do against what the controls prevent. ‍ An insider is already inside. The credentials are valid, the access is entitled and the workflow is familiar. None of that makes the model harder to run, it changes which side of it breaks, and the break is on frequency rather than on magnitude. ‍

The tricky thing about AI compliance is that most organizations are going to experience it from both sides. You need to be able to explain how AI is being used inside your own organization, what it can access, and how you're managing the risk. At the same time, you need to understand how your vendors are using AI and whether that introduces new risk into your environment.

If you manage vendors, supplier drift looks familiar. A delivery arrives late. A vendor misses a service-level agreement (SLA) target, and nobody flags it. Tickets sit unresolved, and quality dips just enough that it never makes the weekly stand-up. The problem is timing. Most teams find out a vendor missed its uptime or response-time targets at renewal, months after anyone could’ve fixed it.

Computers are not safe. Even the best hardware and software products have the potential to conceal as-yet unknown vulnerabilities. And they aren’t all made that well. Many are shuffled into the world without a plan to detect, remediate, and notify users of those vulnerabilities. The EU’s Cyber Resilience Act aims to improve that situation.

An AI assistant reads four hundred documents across a tenant. Every read is logged. The application is named, the file is named, the timestamp is exact, and the access is attributed to an account that belongs to nobody. ‍ The audit trail is complete and it cannot answer the question an auditor asks. Nobody asks whether an access was recorded. They ask who reached the data and whether that person was authorized, and a shared service account answers neither. ‍

Most cyber loss models are shaped around a breach. Records exposed, notification cost per record, regulatory penalty, credit monitoring, litigation. The arithmetic is well established and the inputs are reasonably well evidenced. ‍ Apply that model to an outage where nothing left and nothing was taken and every one of those categories returns zero. The organization was down for four days and the model reports almost no loss, which is not a calibration problem but the wrong model. ‍

In January 2024, Craig Raw, the developer of the real Sparrow Wallet, a Bitcoin wallet app, warned that a fake version of his app was live on the Apple App Store. He reported it repeatedly, but the listing stayed up. By August 2025, three people had lost a combined $1.8 million to it: Jalen Delgado (about $120,000 in May 2025), James Ramirez (about $875,000 in July 2025), and Christopher Ellis (about $840,000 in August 2025). All three are now suing Apple. The complaint, Ramirez, et al. v.