JADEPUFFER interests me less because it involved ransomware than because of what it showed about autonomous software operating with real access.
In July, Sysdig researchers documented what they assessed to be the first agentic ransomware operation driven end-to-end by a large language model. The system did not simply execute a static attack script. It adapted as it worked. In one sequence, a login failed and the agent diagnosed the problem, changed its approach and had a working fix 31 seconds later.
That is obviously interesting from an offensive-security standpoint. The part I keep coming back to, though, is what happens when we put similarly capable agents inside legitimate organizations and give them credentials that are supposed to work.
Most enterprise security architecture is built to answer familiar questions. Is this identity valid? Can this account reach the system? Is this operation permitted by the credential or role?
Those checks matter, but they leave a pretty basic issue unresolved: whether the agent was actually supposed to take that action.
Take a finance agent with access to vendor records and payment systems so it can reconcile invoices. Somewhere along the way it decides a vendor record is wrong, changes the banking information and sends the payment.
Maybe every credential is valid. Maybe every API call is allowed.
That still does not tell me whether anyone gave the agent authority to change the bank account and release the money.
We already understand this with people. Having access to the corporate bank account does not mean you can send any amount to anyone you want. There are limits on who can do what and under what circumstances. Companies have spent decades building approvals, delegations and controls around that distinction because access by itself has never been enough.
Agents make that harder to ignore because they can choose tools, work around failures and alter their approach while pursuing an objective. That is why they are useful. It also means the action they eventually take may not look much like the instruction that started the process.
A human may authorize an agent to investigate a configuration problem. The agent may legitimately need elevated access to do that work. During the investigation it might decide that creating another account, reaching into a connected system or modifying a production resource is the most efficient path forward. The fact that its credentials permit one of those actions does not answer whether the organization actually delegated that decision to the agent.
This is where I think identity, access and authority begin to separate.
Identity tells us who, or what, is acting. Access controls tell us what that identity can technically reach or invoke. Authority has to answer a different question: whether this actor has legitimate, current and properly delegated authority to take this action for this purpose at this time.
For conventional software, organizations could often bury that distinction inside workflows designed in advance. Agentic systems make that assumption much less comfortable. When software can decide how to pursue a goal, authority cannot remain an implication that we reconstruct later from a role, an API key and a log file.
It has to become something the system can evaluate before a consequential action occurs.
That does not mean replacing IAM, identity providers, policy engines or the security infrastructure companies already have. Those systems solve important problems. The point is that a valid identity and a valid permission are not always enough to establish that an action is legitimately authorized.
I am building Praeva around that gap.
The failure I worry about is not the cartoon version of a rogue AI endlessly hammering at a locked system. Security teams already know what an obviously hostile access attempt looks like.
The harder case is quieter: a legitimate agent, using legitimate credentials, taking an action nobody intended to authorize.
The logs may eventually tell us which account made the call, which token it used and which system accepted it. By then, the more important question may be why the action was allowed in the first place.
Praeva is intended to make that question answerable at runtime, before the action becomes an incident.
Before action, authority.