A control architecture for AI and agentic systems
The CORE Framework
You cannot script the actions of something operating faster than you can observe it. You can tell it what the mission is and where the limits are.
Three things you cannot do
AI is hard to govern not because it is powerful or fast-moving — plenty of technologies are both and we govern them adequately. It is hard to govern because three mechanisms we have always used to gain assurance over a system stop working on this one.
-
You cannot predict it.
A deterministic system returns the same output for the same input, which is what makes a test result mean something after the moment of the test. The same prompt can return different answers on different runs, at different temperatures, and after a vendor changes weights behind an endpoint whose name never changed.
-
You cannot inspect it.
We normally reason about what a system will do by reading what it is made of. A model's behavior isn't located anywhere readable — it is spread across billions of parameters as statistical relationships, and access to those parameters tells an auditor nothing about what happens next.
-
You cannot instruct it reliably.
This is the one that fools people, because it appears to work. Instructions and data reach the model through the same channel, so anything the system reads can be taken as something the system was told. A guardrail written in English is a request, not a control.
Every framework you have implemented before assumed at least one of those three. And these systems no longer just produce text — an agent initiates. It calls an API, writes to a database, moves money, provisions a resource, in the time a network request takes. That single change breaks the grammar of the controls you already own: access control asks who is requesting, audit logging records who did it, separation of duties assumes duties are held by people.
Govern the boundary, not the black box
We cannot audit or predict the internal logic of a probabilistic system. Therefore enterprise governance must focus entirely on governing the boundaries: the data it can access, the deterministic gates it cannot breach, the identities it executes under, and the continuous telemetry that measures its variance.
You cannot control what a model concludes. You can control, absolutely, what data it is able to reach. You cannot guarantee it will refuse a dangerous instruction. You can guarantee the operation isn't in its allowlist and its credential cannot perform it. You cannot know what it was thinking. You can record exactly what it was looking at, sign that record, and store it where nobody can alter it.
Every one of those boundary controls is ordinary software — readable, testable, versionable, provable. None of it is probabilistic, none of it waits on interpretability research, and all of it holds regardless of what the model inside the boundary turns out to be. So CORE puts nothing load-bearing inside the model.
The four pillars
Drawn as a loop rather than a stack. Elasticity produces information — a system's data access expanded, a new dependency appeared, an agent is being used for something nobody registered — and that information is Context. It returns to the registry, which changes the trust tier, which changes the operational envelope, which changes the autonomy grant. If the loop doesn't close, you have a waterfall with monitoring bolted on the end.
Context
What the system is allowed to touch
Two questions: what systems do we have, and what data may each one reach? The first is harder than it sounds, because AI enters through channels that generate no procurement signal — a business unit deploys an agent on a purchasing card, a vendor switches on generative features inside software you approved three years ago. Enumeration has to be continuous and adversarial rather than annual and self-reported.
The second question is where the consequential decisions live, and the answers have to be hard boundaries. Some data has no AI exception path at all.
Part I · Chapters 3–6
Oversight
The gates it cannot breach
A deterministic container around a probabilistic engine. Input is inspected before it reaches the model, output validated before it reaches a user or system, generated code executed in a sandbox with no network path out. None of those components are themselves AI — that is the point. Ordinary software can be tested, versioned, and proven.
Autonomy is granted per action class, never as a single setting, and thresholds are drawn around irreversibility and blast radius rather than technical difficulty.
Part II · Chapters 7–10
Responsibility
The identity it executes under
An autonomous system is a non-human identity operating under a delegation of authority from a named human. Agents get individual directory identities, individual credentials, and least-privilege scoping — not shared service accounts. Each is bound to an accountable sponsor, and when that sponsor leaves, authorization is re-attested or suspended.
Ordinary log files won't carry a legal defense, because anyone who can alter files can alter them. Records are hash-chained and written where they cannot be rewritten, so verification is arithmetic rather than testimony.
Part III · Chapters 11–14
Elasticity
The variance measured over time
Systems drift, data environments evolve, and vendors change model behavior behind stable APIs without telling anyone. Live telemetry measures whether the system still behaves the way it behaved when you approved it, and when it doesn't, autonomy degrades automatically instead of waiting for someone to convene a meeting.
Enforcement is a throttle rather than a switch: full autonomy under normal operation, mandatory human review on every write when telemetry degrades, credentials revoked and execution frozen on a verified breach.
Part IV · Chapters 15–18
This is what makes “authorization is a state, not an event” operational rather than rhetorical.
Five questions an executive should be able to answer
You don't need to evaluate the framework on technical grounds to know whether your organization has a problem. The value isn't in the answers — it's in how long the room takes to produce them, and which question is the one where everybody looks at somebody else.
-
How many AI systems are running in production, and who owns each one by name?
If the answer is an estimate, that tells you where you are. A name means a person, not a department. Context
-
What is the most sensitive class of data any of them can reach?
Not what they are supposed to reach. What they can reach, given their actual permissions. Context
-
What is the largest irreversible action any of them can take without a human approving it?
Irreversible is the operative word. Emailing forty thousand customers is irreversible. Moving money is irreversible. Dropping a table is irreversible. Oversight
-
If one of them did something wrong at three in the morning, could you prove which one, and under whose authority it acted?
The standard is not whether you could probably reconstruct it. It is whether the evidence would survive adversarial examination by opposing counsel. Responsibility
-
How would you know if one of them started behaving differently than it did when you approved it?
If the honest answer is that someone would eventually notice, there is no elasticity capability in place. Elasticity
In my experience the room stalls on question four.
What CORE is not
Being clear about the boundaries of a framework is what keeps it from being misused.
- Not a certification. There is no CORE-compliant badge and I am not selling one. It is an architecture for organizing controls, and its output is evidence that maps onto standards other people certify against.
- Not a replacement for ISO/IEC 42001. That standard specifies how an organization manages AI as an ongoing discipline — policy, roles, objectives, internal audit, management review. CORE specifies what the controls should be and how to build them. I use both, for different things.
- Not a risk assessment methodology. It won't tell you how to score or prioritize risk. Use whatever your organization already uses. CORE tells you what to build once you've decided something matters.
- Not a substitute for legal review. Questions of liability, indemnification, and IP ownership in AI outputs are genuinely unsettled in most jurisdictions. Involve counsel early.
- Not a guarantee your AI systems are safe. It will make your organization able to describe, bound, attribute, and monitor them. That is a materially different claim, and it is the only one I am willing to make honestly about a probabilistic system.
On Amazon September 21, 2026
Governance at the Speed of Autonomy
The cybersecurity and data privacy playbook for implementing governance, risk management, and compliance for artificial intelligence and agentic AI.
The framework above is the summary. The book is the implementation: twenty-one chapters, a consolidated playbook, an evidence artifact catalog covering what an assessor will accept and reject for forty-eight controls, an agentic incident response field guide, and a vendor due-diligence questionnaire.
Ask me about it