Who Approved That AI Action? Constitutional Governance for Physical AI

I’m Praveen, an Applied AI Architect here at Edgescale AI, and I’ve spent the past two years making sure our customers can consistently answer that question. To make sure this article is worth your time before you proceed, here are the key concepts I’m going to unpack in this article:

• Why the cloud-AI playbook breaks at the physical (real-world) boundary – and what has to replace it.
• The structural answer to “who approved that AI action?” – a record written before the action, by a separate authority.
• Why the same governance layer that looks like a deployment blocker is the thing that makes Physical AI deployable at scale.

Before we get started, though – a quick note on some key terminology used in this post:

• A Cube is Edgescale’s Physical AI appliance that sits at each customer site, which runs AI locally, keeps their data sovereign, and provides deterministic action on critical systems.
• The Engine is Edgescale’s governance layer between an actor (human or AI agent) and any change to a Cube, to its code, or to its operational context.

Why Constitutional Governance matters for Physical AI

Cloud AI frequently fails forward. Bad inference or a hallucinated tool call results in a retry, patch, and a fix. The action lives in software, which means it can be rolled back.

Physical AI cannot fail forward. A setpoint pushed to a valve, a deploy command sent to a plant network, or a maintenance dispatch transmitted to a crew are all actions that live in reality – in the physical world. There is no undo you can issue from a notebook.

So, picture the failure mode of AI running in the physical world. An AI agent watching your fleet sees a pattern and pushes a configuration update across dozens of sites, then it calls its deploy API, and the update lands. Now ask “who approved that deploy?” In this case, the model decided, the model acted, and no separate record exists. In your existing change-management process, that question always had an answer – an operator’s name, a ticket, a timestamp, a signed-off batch. With the AI agent in the same situation, the answer is “the model wanted to.” And, in my experience, that answer won’t satisfy a regulator, a security team, or an ops director.

That’s the failure mode that Edgescale’s Engine prevents, and it matters now, not later. Engineers are shipping agent code into production against systems that can’t fail forward. The structural property has to be in place before the agent layer matures, not retrofitted after it’s already acting in the world.

Constitutional governance like this is one of the structural properties that distinguishes Physical AI Infrastructure as its own category, not just cloud AI shipped to the edge. The bet we’ve made at Edgescale, based on our experience at thousands of edge sites around the world, is that AI agents at the physical boundary need a constitutional layer between intent and action. The Edgescale Engine is one aspect of that layer.

Today, every change to a real system takes its own path

If you operate distributed compute across a lot of facilities, you’ve probably noticed that every change has its own tool. Operators SSH in, admins push images through a pipeline, and agents query a model and call a webhook. None of those tools share a rule-check, and none of them write to the same audit trail. None of them separate deciding from doing.

While this may not track to your operation perfectly, here’s a common situation we’ve seen with companies we work with (before they deploy the Cube). First, an admin in one region pushes a configuration through a CI/CD pipeline. Then an operator on another shift SSHs in to apply a hotfix. A scheduled job in your dev environment queries a model and calls a webhook to update a deployed cube’s runtime.

That’s three changes, three tools, three different audit trails – all of them landing on the same compute, none of them sharing a rule-check. When the security team asks “who approved each of those?” the answer comes from three places, in three formats, with varying confidence.

That setup used to work because humans are slow, and the volume was small. It worked because, when something went wrong, you could ask the person who did it. But it doesn’t survive contact with AI agents.

AI agents amplify the problem at machine speed

An agent can trigger many more actions in the same window than a human operator. None of them have separate authorization, can produce a record a regulator could read, or give your security team a layer to point to.

It’s not only volume, it’s the unpredictability. A human operator’s actions are bounded by what they know how to do – their training, their tooling, and their habits. An agent’s actions are bounded by what the model pattern-matches to. So an agent might do something a human never would – not because it’s smarter, but because the prompt resembled a different pattern. Without a separate authorization layer, that boundary lives entirely inside the model.

Therefore, your CISO’s question – “How do I know the AI didn’t act before we caught it?” – has no good answer in the cloud-based AI playbook. The compliance question – “Show me who approved each action” – has no good answer either. And same goes for the ops question – “What record do we keep when an agent does something we don’t like?”

The solution: Propose ≠ Admit ≠ Execute

At Edgescale, we solve for this by requiring three distinct roles on every action: propose, admit, execute. And most importantly – the thing that asks is never the thing that approves, and is never the thing that does.

This is the separation of powers, applied to AI actions on real systems through constitutional governance, powered by Edgescale’s Engine.

The Edgescale Engine implements the rule. The Engine is designed to accept any actor – admin, operator, or AI agent – as a proposer. The Engine evaluates the artifact against a registered constitution, writes the result to an append-only store, and only then dispatches the action to the system. The record exists before the action happens, written by a different process than the one that proposed.

The Engine treats humans and AI agents identically by design

The Engine’s architecture sets up three chambers, one audit trail, and one accountability path – for any actor. By design, an AI agent isn’t a special case. It’s just another actor on the same governed path – the same path the agent layer is being built to use.

What that means for a CISO is that every action on the system – whether human-initiated today, or AI-agent-initiated as the agent layer lands – has an admission record written by a separate authority before it acts. The audit question is answerable from first principles, the compliance question has a structural answer, and the security team has a layer to point to.

What that means for an AI builder is that agents become first-class actors on systems that previously felt off-limits to them. Not “we’ll figure out governance later.” Governance must be the prerequisite, and it’s already in place.

What changes for your security team

If you’ve been the person blocking AI rollouts because the governance question wasn’t answered, the Engine changes what’s on your desk.

You’re no longer asking the AI team “How can we trust this?”, because you’re now reading the admission record. The question “Did the agent act before we could review it?” stops being a fear, because the answer is no – because the actuator doesn’t dispatch without an admission stamp. The compliance posture stops being aspirational and starts being structural.
This is a different kind of review – one that focuses on what the AI should do, not on whether the platform can answer for what it did.

Governance is what makes Physical AI deployable at scale

The governance layer that looks like a deployment blocker is precisely what makes Physical AI deployable at scale.

Without it, every AI rollout becomes a one-off security debate. Every conversation with the CISO is about how they can trust this, every conversation with the compliance team is about the audit trail, and every conversation with ops is about what happens when something goes wrong.

With the Engine, governance is a structural property of the platform. The CISO gets a clear view of the admission record and can now focus on what AI should do next. The compliance team isn’t asking for the audit trail – they’re already reading it. The ops team isn’t worried about an unauthorized action – there isn’t one to worry about.

This shifts the AI conversation from defensive (don’t do anything dangerous) to constructive (here’s what we want the agent to handle next). The CISO’s role shifts from blocker to architect. The compliance team’s role shifts from auditor-after-the-fact to subscriber-to-the-store. Each of those shifts is what makes AI deployable on systems that previously required round after round of security review per rollout.

The same answer that unblocks your internal review unblocks the conversation with your technology partners. The CISO’s question about who approved each action is the same one Red Hat, NVIDIA, Palantir, and Hitachi field teams hit when they’re discussing AI inside your environment.

Edgescale’s Engine supplies the structural answer to this for the Physical AI ecosystem, enabling the conversation to move forward, focusing on the business outcomes that need to be delivered.

Constitutional governance isn’t overhead. It’s the thing that makes the rest of the AI deployment possible.

Proof

Here are a few anonymized examples from recent Edgescale deployments:

• A manufacturer was running AI agents against a plant network. Before the Engine, the agent’s tool calls hit the plant systems directly with no separate authorization record. The Engine now sits in the path between the agent and the Edgescale Cube; as the agent layer comes online, each dispatch carries an admission record before any Cube acts. As a result, the agent’s tool call becomes a proposal, not an execution. The security review that previously had no governance answer now has one to point to.
• A customer was running image deploys across a Cube fleet through the Engine. A deploy artifact moves from proposal to admission to a real Cube on their network, and telemetry returns through the same pipeline. The audit trail is the same whether the request came from a human operator or an automated promotion pipeline.
• A third customer still had identity setup in flight when we started. But the Engine was ready day one, just waiting for the blocking work on the upstream identity layer. As soon as identity landed, governance was already in place. They didn’t have to retrofit the policy, since – with the Engine – it’s structurally there from day one.

With the Engine running in production today, customers get the full propose-admit-execute path for all human-initiated requests.

For full transparency, though, what isn’t quite finished yet is that the full agent layer on top of the engine is scaffolded but not yet wired into the runtime. The bootstrap rules currently active are fewer than the design target. Both are tracked and in progress.

Common Misconceptions

• “Isn’t this just another POC?” The Engine runs in production today. Cubes are built and deployed through it. Human-initiated requests pass through the admission path today; the agent layer is being built to use the same path, so when it lands, no new pipeline gets built.
• “My model can self-check.” A model checking its own actions is one entity proposing and admitting. The whole point of separation of powers is that the asker can’t be the approver. Structural separation requires a different process, not a smarter prompt.
• “How is this different from a workflow approval tool?” Workflow approvals are designed for human pace – one form, one approver, minutes per decision. Constitutional governance is the same, but at machine pace, on the call path, with the audit trail as a structural property of admission rather than a separate log.
• “This only matters for highly-regulated industries.” Wrong. The governance question is being asked by every team that wants to put AI into a real operation. Regulated industries asked first because their auditors made them. Unregulated ones are following because their boards are asking the same question – and because once an AI agent damages a piece of physical infrastructure, the question gets asked regardless of regulation.

Conclusion

The question your security team is going to ask before letting an AI agent touch a real system has only one acceptable answer, which requires a record in a store, written by a different process than the one that proposed, addressable by ID, and immutable after admission.

The Engine’s approach – propose, admit, execute – codifies the governance that answers this question.

That’s the prerequisite to deploying AI on systems that can’t fail forward. Get the prerequisite in place, and the conversation can move on to what specific business outcomes AI can enable next.

Governed by the Engine. Built on the Cube.
Get your custom demo today.