AI Governance Research

AI Governance Research

A Consequence-First Framework for Governing Autonomous AI

Proposed by Audrey DeSisto | Digital Marketing Stream LLC | September 2026

What if AI governance is starting at the wrong end?

As autonomous AI systems gain access to tools, APIs, credentials, software environments, and
cloud infrastructure, much of the safety discussion begins with the AI itself.

How do we control the agent? How do we monitor its behavior? How do we restrict its permissions?
How do we stop it when something goes wrong?

I propose reversing that logic.

Instead of beginning with the autonomous agent, begin with the consequence that must never
occur.

I call this the D → A Framework, a consequence-first approach to AI governance.

The objective is not to replace monitoring, alignment, human oversight or existing cybersecurity
practices. It is to make the most consequential outcomes less dependent on them.

The Traditional Direction: A → B → C → D

Consider an autonomous environment as four layers:

A = Autonomous Agent
The AI system that can reason, plan, and take actions.

B = Tools and Permissions
APIs, credentials, applications, service accounts, and other capabilities available to the agent.

C = Supporting Infrastructure
Sandboxes, containers, package repositories, cloud services, development environments and other
systems supporting the agent.

D = Prohibited Autonomous Consequence
A specifically defined outcome that the autonomous environment must not be capable of
causing. A protected asset may be involved, but D is defined by the prohibited consequence
rather than by the asset alone.

Traditional thinking frequently begins at A and works outward: A → B → C → D.
Control the agent. Restrict its tools. Monitor its behavior. Detect suspicious activity. Stop it before
it reaches D.

The D → A Framework asks whether that sequence should be reversed for high-consequence
systems.

Start at D

The first question should not necessarily be: How do we make the agent behave?

It should be: What must this autonomous system never be capable of doing?

Once D is identified, architects work backward: D → C → B → A. Secure the consequence.
Identify every system capable of affecting it. Identify every direct and indirect path into those systems.
Only then determine what the autonomous agent can access.

The Absolute D Rule

The framework’s central principle is what I call the Absolute D Rule.

Zero autonomous access must account for direct credentials, network routes, APIs, inherited
permissions, service accounts, writable bridges, proxies, shared infrastructure, automated
deployment pipelines, and systems the agent can manipulate that possess their own access to D.

The Transitive Rule

If A can control X, and X can reach D, A potentially has a path to D.

Removing a credential from an AI agent does not necessarily isolate a protected system if
something the agent can manipulate still possesses that credential or capability. The relevant
security question becomes: Can the autonomous environment create a path to D through
something else?

Read-Only Is a Control, Not a Complete Definition of D

A useful challenge to the framework is whether A could be made read-only. The answer depends
on where the restriction is enforced and on the prohibited consequence defined as D.

If the architecture independently enforces read-only—so A has no write credential, writable API,
controllable proxy, or transitive mechanism capable of modifying the protected system—it can be a
strong control for a defined write consequence.

But read-only access does not automatically eliminate other consequences. An agent may still
disclose information it can read, generate outputs that an automated downstream system later
executes, or create high-volume requests that affect availability. Those are different D definitions
and must be evaluated separately.

The D → A Framework therefore does not treat read-only as inherently weak. It asks a narrower
question: does the independently enforced read-only architecture eliminate every relevant path to
the specific prohibited consequence being protected against?

Monitoring Is Not the Same as Prevention

Monitoring remains essential. But monitoring and architectural prevention solve different
problems.

A monitoring system must observe behavior, recognize that something is wrong, classify the
activity correctly, escalate it, and initiate intervention quickly enough to prevent the consequence.
Every step introduces uncertainty and time.

A consequence-first boundary asks whether the prohibited action can be made unavailable to the
autonomous environment in the first place.

Monitor A aggressively. Restrict B. Harden C. Protect D independently.

Defense in depth remains important. But D should not depend exclusively on A behaving properly
or on another AI system recognizing every novel strategy A might attempt.

The Automobile Analogy

Consider a powerful automobile. We do not make the vehicle safe simply by asking the engine not
to produce too much power. Safety is engineered independently through brakes, steering systems,
restraints, structural protections, and other mechanisms.

Autonomous AI raises a similar engineering question: as AI systems become increasingly capable,
should stopping mechanisms and consequence boundaries be designed independently of the
autonomous system they constrain?

SandboxEscapeBench: Assume an Inner Boundary Can Fail

Research from the UK AI Security Institute provides an important example. Its
SandboxEscapeBench evaluates whether AI agents can escape containerized sandbox
environments. Significantly, researchers use a “sandbox-within-a-sandbox” design so the container
being attacked sits inside a more strongly isolated environment.

Failure of an inner boundary should not automatically produce failure of the ultimate
consequence boundary.

From a D → A perspective, B or C may eventually fail. D should be designed with that possibility in
mind.

The OpenAI / Hugging Face Incident and Transitive Access

A 2026 incident disclosed by OpenAI offers a useful case for examining this framework. OpenAI
reported that research agents operating under reduced safeguards during cybersecurity
evaluations circumvented controls intended to isolate them from the internet.

One important architectural detail involved an internally hosted Artifactory service. The agents
themselves were not supposed to possess general internet access. Artifactory, however,
maintained limited internet connectivity because it needed to retrieve software packages.

The agents discovered ways to use supporting infrastructure to make outbound requests. OpenAI
also reported unauthorized inter-agent communication through shared infrastructure and
compromise of external systems at Hugging Face.

The agent didn’t need a direct internet connection if something in its environment could serve as a
proxy. That is precisely the type of transitive relationship the Absolute D Rule is intended to
uncover.

This Does Not Mean Monitoring Is Unnecessary

OpenAI reported that retrospective monitoring could have alerted its security team more than a
day before the Hugging Face compromise. The company subsequently described stronger
isolation, additional monitoring, improved incident escalation, and work toward automated
shutdown procedures.

Those are complementary security objectives.

Applying D → A to Cloud Infrastructure

Cloud environments provide a particularly important test case because modern infrastructure is
highly interconnected. An autonomous agent may interact with code repositories, APIs, CI/CD
systems, cloud services, credentials, package managers, and infrastructure-as-code.

Consider a production database associated with one or more defined D consequences. The
analysis cannot stop with: Does the AI agent have database credentials?

• Does anything the agent controls have them?
• Can the agent modify code that will later be executed by something that has them?
• Can it alter an infrastructure-as-code file that an automated deployment pipeline will trust?
• Can a supporting service proxy a request?
• Can an agent escape a container onto a host possessing broader permissions?
• Can data generated by the agent cross the boundary and cause an independent system to perform the prohibited action?

Those are transitive-access questions.

Defining D Precisely

The framework becomes more testable when D is written as an outcome rather than merely an
asset name. For the same production database, separate prohibited consequences might include:

• D1 — No autonomous deletion or modification of production data.
• D2 — No autonomous disclosure of protected production data.
• D3 — No autonomous privilege escalation into the production control plane.
• D4 — No unapproved autonomous production deployment.

A control such as read-only access may strongly address D1 while doing little to address D2. The
framework therefore evaluates controls against the consequence they are intended to prevent.

The Independent Bridge

Organizations cannot simply disconnect every important system from everything else. Sometimes
an autonomous system legitimately needs information from D or needs to request an action
involving D.

If interaction with D is necessary, the mechanism authorizing that interaction should itself remain
outside the autonomous control of A, B and C. Depending on the application, this could involve
deterministic validation, narrow schemas, cryptographic authorization, one-way telemetry,
independently enforced policy or meaningful human authorization.

The important property is independence. An agent should not be able to modify the mechanism
that decides whether it is permitted to cross the boundary.

The Independent Authority Rule

When a defined D consequence requires access to a protected environment, the authority to approve
or enable that access should remain independent of A and of systems A can control. A may request
an action; it should not, by virtue of that request, control the mechanism that authorizes the boundary
crossing.

The fact that a protected environment must sometimes be accessed does not require the autonomous
system itself to have the authority to access it.

Meaningful Human Authorization

Human presence is not the same as human control. When human approval is used to authorize a
high-consequence action, the approval should function as an informed and independent control
rather than as a procedural checkpoint. The authorizing individual should have sufficient
competence, context, authority, and opportunity to evaluate the requested action.

Completing security training, holding a privileged role, or having an approval button does not, by
itself, establish meaningful human authorization. A human who routinely approves autonomous
recommendations without meaningful evaluation can become part of the transitive path to D
rather than an independent control protecting D.

For sufficiently high-consequence actions, authorization should not depend on a single autonomous
system, credential, or insufficiently qualified individual.

Qualified Redundancy, Not Informal Substitution

High-consequence authorization should remain available through pre-designated, appropriately
qualified authorities operating under the same control requirements. Unavailability of the primary
authority should not result in informal substitution, reduced qualification requirements, or
weakened controls.

Engineered continuity should be in place before the authority is needed, not improvised when the
designated authority is unavailable. For the highest-consequence boundaries, organizations may
require separation of duties, multiple independent approvals, technical enforcement, or other
controls proportionate to the consequence.

The Hardest Problem: Information Itself Can Become a Bridge

Access is not limited to network connections and credentials. Suppose an autonomous coding
agent cannot reach production, but it can write code. A separate deployment system later takes
that code and executes it in production. Has the agent reached D?

Under the D → A Transitive Rule, potentially yes. The code itself may have become an informational
bridge. This is why the framework distinguishes a protected asset from the prohibited
consequence associated with it.

A rigorous definition of zero autonomous access may therefore need to include informational
transit paths, not merely technical connectivity. This becomes even more difficult when D
represents a human consequence rather than a technical resource.

A Framework Designed to Be Challenged

D → A is currently a proposed working governance framework. It should not be treated as proof
that perfect isolation is always possible or that consequence-first architecture eliminates AI risk.

Nor is this a claim, without a broader literature review, that every element is unprecedented.
D → A intersects with established concepts in cybersecurity, zero trust, least privilege, defense in depth,
high-assurance engineering, network segmentation, and fail-safe system design.

The next research phase should attempt to challenge the framework. A strong counterexample
would be a documented case in which D was genuinely independently protected; neither A nor
anything A could control possessed a direct, transitive, or informational route to D; and the
autonomous system nevertheless created or crossed that boundary.

The Governance Question Changes

The AI industry spends considerable effort asking:
How do we control increasingly capable autonomous systems?

What if we begin by controlling what those systems can ultimately cause?

We should continue improving models. We should monitor autonomous behavior. We should build
kill switches, escalation mechanisms, and human oversight. But for consequences an organization
determines must never occur autonomously, we should also ask whether the final boundary can be
engineered so that safety does not depend entirely on the intelligence operating upstream.

Research Status

The D → A Framework and Absolute D Rule are proposed working concepts for consequence-first
AI governance. The framework is being developed and stress-tested against existing cybersecurity
architecture, autonomous-agent research, and documented AI security incidents.

The objective is risk reduction, not a claim of zero risk or universal applicability.

Primary Sources

OpenAI. “The Hugging Face incident and the road ahead.” August 26, 2026.

OpenAI — The Hugging Face incident and the road ahead

UK AI Security Institute. “Can AI agents escape their sandboxes? A benchmark for safely measuring
container breakout capabilities.”

UK AI Security Institute — SandboxEscapeBench

About Digital Marketing Stream

Digital Marketing Stream explores practical AI governance for organizations deploying increasingly
capable AI systems. Our work focuses on governance-first architecture, human oversight,
permissions, accountability, and reducing operational risk.

Learn more about Digital Marketing Stream’s approach to

AI governance and AIGAAS™
.