Why compiled safety must sit below policy¶

October 4, 2026 · Kishore Babu Gutta

Policy is configurable.

Safety should not always be.

That distinction matters when a runtime is allowed to execute engineering operations on behalf of humans, automation or AI agents.

Engineering Runtime therefore treats some protections as a compiled safety floor rather than ordinary configurable policy.

Policy is allowed to change¶

Organisations need different rules.

One team may permit repository creation.

Another may deny it.

One environment may allow a deployment operation.

Another may require it to be blocked.

That is exactly what configurable policy is for.

request
  ↓
compiled safety
  ↓
organisation policy
  ↓
auth + context
  ↓
execution

But some classes of operation should not become executable merely because a policy file says they are allowed.

The problem with making everything policy¶

If every protection is represented only as configurable policy, then the same configuration system that grants normal access can also disable the runtime's last line of defence.

That creates an undesirable property:

unsafe operation
      +
permissive / mistaken policy
      ↓
execution allowed

For a governed execution layer, that is too weak.

A policy author, automation error or compromised agent should not be able to convert every runtime guardrail into an opt-out setting.

The compiled safety floor¶

The alternative is a layered model.

Intent
  ↓
Compiled safety floor
  ↓
Configurable policy
  ↓
Auth / context
  ↓
Execution

The compiled layer contains protections the Runtime itself refuses to cross.

Policy sits above that floor.

Policy can deny more.

It cannot permit what the compiled safety contract already refuses.

Policy may narrow the execution surface. It cannot expand beyond the compiled safety floor.

Why this matters for agents¶

An AI agent may generate a dangerous command, REST request or provider operation.

That does not mean the Runtime should attempt it and hope policy catches it.

Where a class of operation is known to violate the Runtime's non-negotiable safety contract, it should be rejected before provider execution.

agent proposes operation
        ↓
compiled safety check
        ↓
DENIED
        ↓
provider never receives request

The same principle applies whether the underlying transport is:

a native CLI,
REST,
GraphQL,
a file operation,
or a future execution transport.

The safety property belongs to the Runtime boundary, not to one interface.

Why compile it¶

"Compiled" does not mean every dangerous operation in the world can be predicted.

It means the Runtime ships with a minimum set of protections that are part of the executable contract itself rather than optional organisation configuration.

That gives the system a stable invariant:

There are operations Runtime will refuse even when the caller, agent or policy asks for them.

This is a safety floor, not a complete security model.

Configurable policy, authentication, target context, provider permissions and external controls still matter.

The point is that none of them can silently disable the Runtime's minimum protection boundary.

The design principle¶

A useful way to think about the layers is:

Compiled safety = what Runtime will never do
Policy          = what this organisation allows
Auth            = who may act
Context         = where they may act
Execution       = what is finally dispatched

That separation is important for governed agent execution.

When the caller can reason freely, the execution layer needs some constraints that are not negotiable.