In September 2023, an attacker called MGM Resorts IT help desk, spent about ten minutes on the phone pretending to be an employee, and walked away with the access that eventually took the company's computers offline for ten days. No zero-day. No malware at the front door. Just a phone call and a help desk built to be helpful. I keep coming back to that incident because of how unremarkable the entry point was. We spend enormous energy hardening login pages and MFA prompts, and the breach started with a reset request the system was designed to honor. That gap, between the controls we invest in and the path attackers actually take, is what I want to talk about.
Identity stopped being plumbing
For most of its history, identity was infrastructure you set up once and tried not to think about again. You spun up a directory, federated your apps, turned on single sign-on, and moved on. The job was to get the right people into the right systems with as little friction as possible. Security mattered, but it lived at the edges: a firewall here, a VPN there, MFA turned on when the auditors asked.
That model assumed two things that are no longer true. It assumed there was a perimeter, a clean line between inside and outside. And it assumed the population you were securing was made up of people, a familiar set of employees who logged in from known machines.
Both assumptions have quietly collapsed, and the breaches of the last few years are the proof. The MGM attack did not defeat MFA with some clever cryptographic break. It went around the whole apparatus by talking to a human. When Okta's support system was breached the same year, attackers did not crack a password either. They pulled session tokens out of diagnostic files that customers had uploaded for troubleshooting, then replayed those tokens to impersonate already-authenticated administrators. Five customers had live sessions hijacked, and at least one saw the attack pivot into its internal systems. The authentication had already succeeded. The attacker just borrowed the result.
In each case the identity system was working exactly as designed. The help desk reset the account. The support tool stored the file. The token proved a valid session. Nothing malfunctioned. The threat model was simply built for a different era.
The population changed, and it is still changing
The other shift is who, or what, is actually logging in. For years the non-human identities in an environment, the service accounts and API keys and machine credentials, were a quiet background population that outnumbered employees by some large multiple nobody could count precisely. That was already a governance problem. Most teams could not produce an accurate list of their service accounts, let alone tell you which ones still mattered.
Now AI agents are arriving, and they change the math again. An agent is not a static service account. It acts, it makes decisions, it calls other systems on a user's behalf, and it can be spun up by a developer in an afternoon without anyone filing a ticket. The scale is different by orders of magnitude, and the behavior is far less predictable than a script that runs the same task on a schedule.
This is the part the incumbents have not solved, and I do not think they can solve it by patching. Every major identity breach of recent years traces back to a foundation built for a smaller, slower, mostly human world. Bolting agent support onto that foundation gives you agent-shaped problems on top of a base that was already cracking.
What a secure core actually requires
If the core is now the highest-value target in the environment and the most populated, then "secure" has to mean something more specific than strong passwords and a good MFA prompt. A few principles have shaped how we think about it.
Assume the platform itself can be turned against you. The uncomfortable lesson of the Okta support breach is that the identity vendor can become the attack vector. So the first question I ask of any identity core is not "how does it authenticate users" but "what happens when the platform is compromised." The right answer is that a compromise of the vendor should not be enough to compromise the customer. That means no standing position of trust where the platform alone holds the keys to your kingdom. It means authentication that is phishing-resistant by default rather than as an upgrade, because the help desk reset and the replayed token are both, at bottom, failures of trust that were too easy to assume.
Count every unseen identity as an unmanaged risk. Full control requires full discoverability, full visibility. Every one of these breaches involved an identity that someone had lost track of: a service account stored in the wrong place, a privileged user whose reset path nobody had hardened. Before you can govern anything, you need an honest inventory of every identity across the stack you already have. That means looking into Okta, Entra, Active Directory, and the agents nobody formally provisioned, and treating discovery as a continuous practice rather than a one-time audit. The accounts you do not know about are the ones that get used against you.
Treat agents as first-class identities, not as a special case. The temptation is to handle agents with a side mechanism, a separate vault of secrets stapled onto the human identity system. That is how you end up with the same blind spots one layer down. An agent should be issued, managed, governed, and contained using the same principles you apply to a person, even when it is acting on a human's behalf. In a delegated flow, the agent is still its own identity, and you should be able to see and control it as one. If your core cannot represent an agent as a real principal, it will represent it as a gap.
Govern at machine speed. Govern at machine scale. The agentic era will move at a pace the human-focused era never had to imagine. Agents and machine credentials are created in seconds, act in milliseconds, and may live for an hour. A control that takes a week to apply to an identity that exists for an afternoon is not a control; it is documentation. The core has to issue, scope, rotate, and revoke automatically, at the same speed identities appear and act, because any review that runs on a human calendar is a snapshot of a population that has already changed. Scale is not an operational nicety here. It is a security property, and a core that cannot keep pace cannot claim to govern.
This is not an exotic wish list; it is the new floor. It is mostly the discipline of refusing to assume trust at the points where the old model took it for granted: the vendor, the unseen account, the helpful reset, the inherited session.
Where this leaves us
At NewCore we designed the platform around the idea that we should not be able to compromise our own customers even if we wanted to. Our Secure Split Key mechanism is the concrete expression of that: the platform never sits as a single point of catastrophic trust, so a compromise of the provider is not a compromise of the customer's identities. We pair that with discovery that maps the human and agentic identities already living in your stack, and with agent identity that treats those agents as first-class principals from the start. I am not claiming we have finished the work. A new foundation has to be built for this threat model rather than retrofitted to it.
The breaches keep teaching the same lesson, and it is not that people need better passwords. It is that the core of identity has become the thing worth attacking, and a core built for a calmer world will keep failing in ways that look, in the post-mortem, entirely by design. The work now is to build a core that assumes the attack, sees everything, and treats every identity as something to be governed rather than trusted.