Authentication proves who you are. Authorisation proves what you’re allowed to do. Neither proves that this exact execution was actually authorised.
For thirty years we’ve protected APIs using the same pattern:
TLS
↓
Authentication
↓
Authorization
↓
Business Logic
It has served us remarkably well.
The caller proves their identity.
The server checks permissions.
If everything looks good, the endpoint executes.
But there is a question almost no software asks.
Can you prove this exact execution was authorised?
Not:
Who are you?
Not:
Are you generally allowed?
But:
Can you prove that this exact refund, against this exact customer, for this exact amount, was independently authorised?
That missing question is becoming impossible to ignore.
Not because of AI.
Because AI has exposed a weakness that has always existed.
The illusion we’ve lived with
Consider a refund endpoint.
@app.post("/refund")
def refund():
authenticate()
authorize("refund")
stripe.refund(...)
If the caller has the correct identity and role…
the refund executes.
That’s how almost every API works today.
The assumption is:
If the caller is trusted, every request they send is trusted.
That assumption used to be mostly acceptable.
It no longer is.
AI didn’t create the problem
Imagine four callers.
Human
↓
Microservice
↓
Scheduled Job
↓
AI Agent
Every one of them eventually calls:
POST /refund
The endpoint cannot tell the difference.
Nor should it.
It only sees:
Identity
Permissions
Request
The vulnerability isn’t “AI.”
The vulnerability is that execution itself is never independently verified.
AI simply made that obvious.
Authentication answers the wrong question
Authentication asks:
Who are you?
Authorization asks:
Are you allowed?
Execution verification asks:
Was this exact action authorised?
Those are different questions.
Consider these refund requests.
Refund £50
Refund £500
Refund £5,000
The same identity.
The same role.
The same endpoint.
Only one should execute.
Traditional authorization often has no way to distinguish them.
Identity is not intent
A valid JWT proves:
Alice called this endpoint.
It does not prove:
Alice authorised THIS refund
to THIS customer
for THIS amount
at THIS time.
Those are completely different security properties.
Execution Verification
Instead of trusting the request…
trust a cryptographic proof that binds:
- action
- parameters
- target
- audience
- expiry
- tenant
- approvals
- policy
to a single execution.
The endpoint becomes:
@app.post("/refund")
def refund(request):
kernel.verify(request.proof)
issue_refund()
The endpoint no longer trusts the caller.
It trusts the proof.
Why this isn’t an AI product
One of the biggest misconceptions about Actenon is that it’s “AI security.”
It isn’t.
The kernel doesn’t know whether the request came from:
- an AI agent
- a human
- a webhook
- a mobile app
- a backend service
- a cron job
- GitHub Actions
- an MCP server
It doesn’t care.
It asks exactly one question:
Can you prove this execution was authorised?
If yes…
execute.
If not…
refuse.
AI simply exposed the missing layer
Large language models didn’t invent unauthorised execution.
They simply made software capable of generating actions faster than humans can supervise them.
That exposed a gap that already existed.
We already have:
Encryption
Identity
Authorization
We’re missing:
Execution Verification
Think about payments
Stripe doesn’t trust a random HTTP request.
It verifies:
- signatures
- idempotency
- request integrity
before money moves.
We don’t do the equivalent for most APIs.
Instead we say:
User authenticated?
↓
Role correct?
↓
Execute.
We’re trusting identity…
instead of trusting execution.
The new execution stack
I think future API stacks will look more like this.
TLS
↓
Authentication
↓
Authorisation
↓
Execution Verification
↓
Business Logic
Execution verification becomes the final cryptographic checkpoint before any consequential side effect.
What counts as a consequential side effect?
Not everything needs execution verification.
Reading a public profile probably doesn’t.
These probably do:
- refunds
- payments
- deployments
- IAM changes
- production configuration
- GitHub publication
- customer deletion
- data export
- database migration
- key rotation
Anywhere software changes reality…
execution verification belongs.
This isn’t replacing OAuth
Execution verification doesn’t compete with:
- OAuth
- JWT
- API gateways
- IAM
- policy engines
It complements them.
Authentication proves who.
Authorization proves what.
Execution verification proves this exact execution.
Those are separate security properties.
Why I think this becomes a standard layer
The number of autonomous systems generating actions is increasing rapidly.
Whether those actions come from:
- humans
- AI
- workflows
- automation
- background services
the endpoint has the same problem.
It needs confidence that the action reaching business logic is the action that was actually authorised.
I don’t think that’s an AI feature.
I think it’s an infrastructure primitive.
Closing
Twenty years ago we added authentication everywhere.
Then authorisation.
I think the next layer is execution verification.
Not because AI demands it.
Because software finally exposed that we’ve never had it.
Authentication proves who called.
Authorisation proves what they’re generally allowed to do.
Execution verification proves that this exact action should happen.
That’s a different guarantee.
And I think it’s going to become a standard part of every consequential API.
Top comments (0)