Ross Buckley

Agreed, that ordering is very close to how I see it: map the execution surface, trace what actually runs, enforce at the boundary, and treat model reasoning as secondary.

The distinction I’d add is between observability and authority.

Gatewaying model and tool calls gives you excellent correlation and telemetry, but it only becomes a control when the final boundary can refuse the action from somewhere the process cannot modify or bypass.

There is also an important coverage gap before runtime. Not every consequential action necessarily passes through an obvious model or tool gateway: an agent can call a cloud SDK directly, invoke subprocess, write through a filesystem API, execute SQL through a client object, or use an inherited credential.

That is the reason for the sequence I’m working on with GitHub.com/Actenon:

actenon-scan maps the consequential execution sinks in the codebase before deployment.

Gateway and kernel telemetry show which path was actually taken and propagate the execution identity.

actenon-kernel verifies operation-bound authority immediately before the consequential action and returns ALLOW or a typed refusal.

A receipt then binds the decision to the action and context that were actually presented.

So yes: reasoning last and execution first. I’d just make the middle distinction explicit:

capture tells us what happened; an unreachable boundary decides whether it may happen.

@cperkins-nm yes, this is exactly where showing the mechanism is more useful than debating terminology.

Actenon is not proposing that the model consult another advisory rule. The decision is verified outside the agent at the execution boundary.

The flow is:

actenon-scan maps the consequential action surface.

A permit binds authority to a specific operation, resource, parameters, principal and validity window.

actenon-kernel independently verifies that proof immediately before execution and returns either an executable decision or a typed refusal.

A receipt records what was authorised and what actually happened.

So the distinction I’m making is not “valid credential versus invalid credential.”

It is:

Credential: this bearer can access the system.

Operation-bound authority: this workload may perform this exact consequential action, against this exact resource, under these conditions, now.

That matters even when there is no behavioural novelty.

For example, suppose the converter legitimately opens and writes files thousands of times a day. An attacker causes it to overwrite a sensitive but reachable path using the same familiar syscalls. Its recorded behaviour may look normal. The operation can still be refused because the presented authority does not cover that target or action hash.

The reverse is also important: a legitimate first-time action need not be permanently rejected merely because it is novel. It can be admitted through an explicit grant and leave a verifiable receipt.

That is why I see the layers as complementary:

• historical behaviour detects deviation;
• immutable confinement removes impossible capabilities;
• operation-bound authority governs the consequential capabilities that remain.

We have implemented the open pieces rather than just written the principle:

• actenon-scan for discovering unguarded consequential actions;
• actenon-permit for issuing constrained authority;
• actenon-kernel for independent ALLOW or typed refusal at the execution edge.

I’m interested in testing the overlap rather than claiming one replaces the other. A useful joint test would be a converter workload containing:

1. a novel unauthorised action;
2. a familiar action against an unauthorised target;
3. a legitimate first-time action carrying explicit authority.

That would expose precisely what each boundary catches.

I think we’re converging on the same architectural direction: don’t rely on the model alone. The question for me is where that trust is enforced.

Whether it’s a protocol, a runtime or an operating environment, the important property is that consequential actions cross an independent authority boundary that can allow or refuse execution regardless of which model, agent framework or prompt is involved.

That’s actually what led me to build Actenon. I started with GitHub.com/actenon/actenon-scan because before you can enforce authority, you first need to know what consequential actions an agent can actually reach.

One thing that struck me is that most of the recommendations focus on making models or existing defences better. Those are important, but they still leave the model holding implicit authority over real-world actions.

I wonder if we need to move the trust boundary instead. Rather than asking “did the model decide correctly?”, ask “does this action have explicit authority to execute?” If every consequential action (shell, filesystem, cloud APIs, payments, emails, etc.) had to cross an independent execution boundary that could verify authority before it happened, then improving models becomes one layer of defence rather than the only layer.

That feels like a more fundamental architectural shift than simply adding more safeguards to the model itself.

One thing this timeline reinforced for me is that we still don’t have good visibility into an agent’s execution surface. We spend a lot of time discussing prompts, planning and model behaviour, but much less time asking a simple engineering question: “What consequential actions can this agent actually perform?” Once an agent can write files, invoke shell commands, modify cloud resources or make authenticated API calls, understanding and constraining that execution surface feels just as important as evaluating the model itself.