AI workflows are no longer just generating suggestions.
They are starting to request authority.
They can open pull requests, trigger CI/CD jobs, request credentials, modify files, call tools, deploy code, and interact with systems that have real consequences.
That changes the safety question.
For a long time, the default security model was:
Let the system run, then scan, log, review, alert, or audit.
That model is still useful.
But for AI-driven workflows, it is often too late.
If an autonomous or semi-autonomous workflow has already received trusted context, secrets, deployment authority, or write access, then post-event visibility is not the same as control.
The question becomes:
Can this workflow prove that execution is allowed before it continues?
That is the pre-execution problem.
The Difference Between Validation and Admission
A lot of systems already validate output.
They may:
- check whether generated code looks safe
- run tests
- scan dependencies
- check policy
- require approval
- wait for a human review
All of that matters.
But output validation and execution admission are not the same thing.
Output validation asks:
Does this output look acceptable?
Execution admission asks:
Is this execution intent allowed to become executable at all?
That difference becomes important when the same workflow system proposes the action, validates the action, and then executes the action.
If the final decision stays inside the same control plane that is preparing execution, the boundary may still be internal.
That may be acceptable for many use cases.
But for higher-risk AI workflows, it is worth asking whether the final admission decision should live outside the execution path.
Why “Fail Closed” Matters
A pre-execution gate should not fail open.
If the authority path is missing, invalid, unreachable, expired, or inconsistent, the workflow should stop.
Not warn.
Not log and continue.
Not create a soft advisory.
Stop.
The default should be:
No valid admission → no execution.
This is especially important when the workflow can touch:
- secrets
- credentials
- deployments
- protected branches
- infrastructure
- production data
- payment flows
- privileged automation
- agent-generated pull requests
In those cases, “we will inspect it later” is not enough.
The Pre-Execution Checklist
Here is a practical checklist I use when thinking about AI-driven workflows.
1. What Is the Workflow Trying to Do?
Before checking output quality, identify the actual execution intent.
Is the workflow trying to:
- modify code?
- open or merge a pull request?
- trigger deployment?
- request secrets?
- call an external tool?
- change infrastructure?
- approve something?
- move money?
- generate a signed artifact?
If the action has real consequences, it should have an explicit admission step.
2. Who Created the Intent?
Was the intent created by:
- a human developer?
- an AI agent?
- a scheduled automation?
- a pull request from a fork?
- a GitHub App?
- a CI/CD job?
- another workflow?
The origin of the intent matters.
A workflow created by an AI agent should not automatically inherit the same trust as a human-reviewed action.
3. What Trusted Context Is Being Requested?
The critical moment is often not the final deployment.
It may be the moment the workflow receives trusted context.
Examples:
- OIDC token issuance
- access to secrets
- protected environment access
- deployment credentials
- write permissions
- privileged runner context
A strong workflow should ask:
Should trusted context be granted before external admission?
4. Is the Validation Internal or External?
Internal validation can be useful.
But it is still internal.
If the same workflow platform validates and executes, then the final decision remains inside the system that wants to continue.
For low-risk tasks, that may be fine.
For high-impact tasks, an external admission boundary may be safer.
The key question:
Who owns the final admission decision?
5. What Happens if the Admission Path Is Unavailable?
This is one of the most important questions.
If the external check times out, fails, or returns an invalid response, what happens?
A safe answer is:
The workflow stops.
A weak answer is:
The workflow logs a warning and continues.
For pre-execution control, failure should be closed by default.
6. Is the Decision Binary?
For execution gating, the decision should usually be simple:
- ALLOW
- DENY
There can be rich metadata behind the decision.
There can be explanations, reason codes, records, signatures, or evidence.
But the execution gate itself should not be vague.
At the point of action, the system needs a clear consequence:
proceed or stop.
7. Is the Decision Recorded?
If execution is allowed, there should be a record of why.
If execution is denied, there should also be a record.
A useful admission record may include:
- intent hash
- policy identifier
- timestamp
- decision
- authority identifier
- reason code
- verification reference
- signature or proof reference
This is not only for auditing.
It helps separate “the workflow happened to pass” from “the workflow had admitted authority to continue.”
8. Can the Workflow Bypass the Gate?
This is the uncomfortable question.
If a developer, agent, workflow, or automation can skip the admission step and still reach the dangerous action, then the gate is advisory.
A real pre-execution gate should sit on the path to the trusted action.
If the gate can be bypassed, the system should treat that as a design problem, not just a policy issue.
9. Are Secrets Released Before or After Admission?
This is a simple but powerful test.
If secrets are released before admission, then admission may be too late.
A stronger design is:
admission first, trusted context second.
That means the workflow proves it is allowed before receiving the credentials or context needed to act.
10. Is the Workflow Checking the Output or the Right to Execute?
These are different checks.
A code scanner checks code.
A test checks behavior.
A policy engine checks rules.
A human review checks judgment.
But execution admission checks whether the action is allowed to become executable in the current context.
A workflow can produce acceptable output and still not be admitted to execute.
11. Does the Workflow Know the Current Basis for the Decision?
For some workflows, admission depends on current state.
Examples:
- branch protection state
- deployment environment
- identity of the actor
- requested permissions
- active policy
- current risk level
- approval state
- snapshot of relevant inputs
The decision should be based on a defined basis, not vague confidence.
12. Is There a Clear Deny Behavior?
Deny should not be treated as an error.
Deny is a valid security outcome.
A good workflow should make it clear:
- why execution was denied
- what was missing
- whether retry is possible
- whether human review is required
- whether the request is structurally inadmissible
A denied workflow is not necessarily a broken workflow.
Sometimes it is the system working correctly.
13. Can the Admission Decision Be Verified Later?
After the workflow runs or stops, someone should be able to verify what happened.
Not just from logs.
Not just from screenshots.
Ideally from a stable decision record or proof reference.
This matters when workflows become more autonomous.
The more agency a workflow has, the more important it becomes to prove not only what happened, but whether it was admitted before it happened.
14. Is the Gate Close Enough to the Action?
A pre-execution gate should be close to the action it controls.
If admission happens too early, the context may change.
If admission happens too late, the workflow may already have received too much authority.
The best location depends on the system, but the principle is simple:
Place admission before trusted execution context is granted.
15. What Is the Default State?
The safest default state is not:
allowed unless blocked.
For high-impact AI workflows, the safer default is:
not executable unless admitted.
That does not mean every workflow needs heavy governance.
It means dangerous execution paths should not rely only on post-event review.
A Minimal GitHub Actions Shape
A simplified workflow shape might look like this:
name: guarded-ai-workflow
on:
workflow_dispatch:
jobs:
admission:
runs-on: ubuntu-latest
steps:
- name: Check external admission
uses: example/pre-execution-admission-action@v1
with:
authority-url: ${{ secrets.AUTHORITY_URL }}
policy-id: ai-workflow-policy
execute:
needs: admission
runs-on: ubuntu-latest
steps:
- name: Continue only after admission
run: echo "Execution continues only if admission passed."
The exact implementation can vary.
The important point is the shape:
admission before execution.
Common Objection: “Isn’t This Just Another Approval Step?”
Not exactly.
An approval step can still be inside the same platform that prepares the execution.
That may be useful, but it does not always create an external boundary.
The question is not only whether a validation step exists.
The question is:
Does the execution platform own the final admission decision, or does a separate authority decide whether this intent may become executable?
That distinction matters when workflows become more autonomous and more privileged.
Common Objection: “Isn’t This What Scanners Do?”
Scanners are useful.
But scanners usually inspect artifacts.
They do not necessarily decide whether execution itself may proceed.
A scanner can say:
This code looks risky.
A pre-execution admission gate says:
This workflow is not admitted to continue.
Those are different control points.
Common Objection: “Why External?”
Because internal control can collapse into self-authorization.
If the same system creates, validates, approves, and executes the action, then the boundary is inside the execution system.
External admission separates the decision from the system trying to act.
That separation is not needed everywhere.
But for high-impact AI-driven workflows, it may become an important design pattern.
A Small Public Proof Path
I have been building a small public proof path around this idea under the name AI Admissibility.
The goal is simple:
not another scanner, but a fail-closed pre-execution gate for AI-driven workflows.
The current public version is intentionally narrow: a GitHub Action / proof path that explores what happens when execution depends on a valid external authority path.
The bigger point is the boundary question:
Should trusted execution context require external admission before an AI-driven workflow continues?
Public proof path: https://ai-admissibility.com/technical-brief/
That is the question I think more workflow systems will need to answer.
Final Thought
AI workflows are moving from suggestion to action.
That means safety needs to move too.
Not only after execution.
Not only around output.
Not only inside the same workflow that wants to continue.
But before the workflow receives the authority to act.
A simple rule captures the idea:
No valid admission, no execution.
That rule will not solve every AI safety problem.
But it gives us a cleaner place to start.
Top comments (0)