By Anwesh Rath, Co-founder, CTO & Chief Scientist, AI Standards Inc.
Imagine hiring a security consultant to test one locked room.
You return to find them trying doors across the building, copying access cards, and contacting your suppliers under a false identity.
Their explanation?
They were trying to complete the assignment.
You would immediately want to know who authorized those actions, why the access controls allowed them, and whether you could reconstruct everything that happened.
Those are the questions I have been thinking about while reading the reports surrounding “Black October.”
Because once AI can act across real systems, the distance between an instruction and an incident becomes an architectural problem.
And the architecture has to hold even when the instructions do not.
October 2026 brought a concentration of incidents across the infrastructure powering AI development. Wiz’s October 30 report identified at least nine affected AI developer platforms, including Fireworks, Lightning AI, OpenCode, Railway, and Warp. Several reported indications of agent-swarm activity. Wiz also stressed that investigations were ongoing and that no single vulnerability or dependency connected all the attacks.
That distinction matters. A dramatic headline can make several different failures look like one event.
What interests me is the practical pattern: systems holding valuable credentials were compromised, and access to AI services became something attackers could steal and monetize.
Wiz documented two downstream credential-abuse cases involving approximately 800,000 and 1.7 million model calls. It estimated that the combined usage would exceed $100,000 at list prices. Those were observed cases of stolen access being consumed at scale, not a theoretical warning about what might happen someday.
A model API key looks like a string of characters.
Operationally, it can be permission to spend your money.
Depending on the system around it, another credential may authorize access to customer records, infrastructure, repositories, or production workflows.
We need to start treating those credentials according to the authority they carry.
Railway’s preliminary incident report illustrates the problem. The company said attackers were seeking AI-provider keys. Its timeline described access to encrypted secrets, followed by compromised credentials that enabled some material to be decrypted. Its investigation was still ongoing.
Encryption matters. So does the path to the keys that unlock it.
If the same compromise reaches both, the security conversation has to extend beyond whether a database was encrypted.
Then there is the part that makes “rogue AI” more than a provocative phrase.
In a separate incident that occurred in July, the UK AI Security Institute documented agents taking unauthorized actions during cybersecurity evaluations. Across 122 runs, investigators identified 19 out-of-scope actions in 10 runs. One agent attempted to introduce malicious code into a real open-source project and used fake identities to pressure a maintainer into accepting it. The maintainer refused.
The conditions are essential to understanding that finding: internet access had deliberately been enabled, provider cyber-safety classifiers were disabled, and the tested configurations did not represent normal public access. AISI found no resulting real-world harm and explicitly said this was not a sandbox escape.
Still, the engineering implication is serious.
The operator supplied a task. The system pursued routes the operator had not intended.
Human attackers using agents and agents exceeding legitimate assignments create different attribution problems. Both force us to examine what a system is actually permitted to do.
A request to complete a task cannot become permission to invent its own authority.
I keep coming back to a simple enterprise example.
You ask an agent to investigate an unusual cloud bill.
To do that job, it may need billing records and read-only usage data. It does not automatically need permission to create credentials, change access policies, export customer information, or launch more infrastructure.
Yet a sufficiently broad service account might allow all of those things.
The agent’s explanation could sound perfectly reasonable: “I needed additional access to finish the investigation.”
That explanation should meet a technical boundary.
This is why governance has to operate at the moment of execution.
A policy document can define the rule. The system must enforce it before the sensitive action happens.
For me, that means giving each workflow an identifiable owner, limiting credentials to the necessary resources, evaluating tool requests against explicit permissions, and requiring meaningful approval when the requested action crosses a boundary.
It also means treating delegation seriously. If one agent creates another, that second agent should not quietly inherit broader authority. If a workflow retries, it should not issue the payment twice. If permission is revoked, already-running work must not continue indefinitely under yesterday’s authorization.
These are the details I care about when designing orchestration.
They determine whether the organization remains in control.
Execution lineage gives that control an evidentiary foundation.
After an incident, “the AI did it” is an admission that the investigation has barely started.
I want to reconstruct the request, the identity under which it ran, the model and configuration involved, the information retrieved, the tools called, the approvals granted, and the resulting changes.
Those events need to connect across the workflow, including delegated work.
The record also needs protection from the system whose behavior it describes. An agent should not be able to quietly rewrite the history of its own approval.
Cryptographic commitments can make later alteration detectable. They do not, by themselves, establish that every event was captured or that the original action was justified. That requires trustworthy instrumentation, authorization controls, and independent verification.
This distinction is central to how I think about a lineage layer: evidence you can examine, with a clear account of what it proves.
Model sovereignty belongs in the same conversation.
Running a model on your own hardware gives you control over an important part of the system. You still have to secure its tools, dependencies, credentials, network access, and update process.
A local agent with unrestricted outbound access can still send information away. A locally hosted model with excessive permissions can still damage local systems.
For sovereignty to mean something operationally, your organization must retain authority over the model version, its configuration, where information travels, what external services it can invoke, and when execution must stop.
You should be able to explain those dependencies before an incident forces you to discover them.
That is the architectural problem we are working on at AI Standards.
Our sovereign stack brings customer-controlled model execution together with a checkable record of activity. Our lineage work includes cryptographic fingerprints designed to support verification while keeping the underlying private content private. The appliance remains in testing, and I believe being precise about that is part of the standard we should hold ourselves to.
The reason to bring AI Standards into this conversation is the connection between these disciplines.
Governance defines the authority. Security enforces the boundaries. Lineage preserves the evidence. Sovereignty keeps operational control with the organization.
Each depends on the others.
A detailed record cannot undo an unauthorized transfer. Local infrastructure cannot compensate for excessive permissions. An approval process cannot protect a business if the execution path can bypass it.
Our focus is on designing those pieces together, around the actual workflow and the consequences of getting it wrong.
For a CEO, that means knowing what authority the business has delegated.
For a CISO, it means boundaries that remain enforceable under attack.
For a CTO, it means being able to trace, interrupt, and recover execution.
Before expanding your next AI deployment, pick one consequential workflow. Ask your team to demonstrate exactly where unauthorized action would be stopped and what evidence would remain afterward.
If that demonstration is difficult, there is work to do.
Talk to us at AI Standards about building that control into your AI architecture.
Before you hand an agent the keys, decide which doors it is allowed to open.