The difficult part starts after permission
Agent systems are getting better at deciding what they want to do and at connecting to tools that can do it. That makes a basic question increasingly important: what exactly do we know after an agent takes an action?
A permission check can tell us that an action was allowed. A tool response can tell us what the tool reported. A log can tell us what one component says happened. None of those, by itself, proves the complete execution story.
The gap between permission and proof is where I have been concentrating much of the recent Frequency work.
Permission is only one state in the chain
Frequency Agent Execution Assurance is being built around a stricter separation of states that are often collapsed into one word such as “allowed,” “successful,” or “verified.”
An agent can request an action. Policy can permit a bounded version of that action. The environment can make more capability effectively reachable than the policy intended. The tool can execute something. State can change. Evidence can then support some claims about what happened — but not necessarily every claim we would like to make.
Those are different facts. Treating them as interchangeable makes assurance weaker precisely when systems become more capable.
The execution chain Frequency is trying to preserve
The model I am working toward is deliberately explicit:
Intent
↓
Requested Action
↓
Policy Decision
↓
Effective Authority
↓
Execution Boundary
↓
Observed Side Effects
↓
Drift / Result
↓
Evidence + Receipt
↓
Bounded ClaimEach transition should be inspectable. More importantly, evidence created at one stage should not silently be promoted into proof of another stage.
Effective authority matters more than declared authority alone
One of the most important distinctions is between declared authority and effective authority.
A tool may advertise a narrow operation while the credentials, filesystem, network path, runtime privileges, delegated token, or surrounding execution environment make substantially more capability reachable. If we only inspect the declared interface, we can miss the actual boundary the agent is crossing.
Frequency therefore treats effective capability as something that has to be reasoned about at the moment of action, not as a static property of the tool description.
Execution evidence needs independence
Another recurring problem is self-attestation. If the same component performs an action and produces the only evidence that the action was performed correctly, the evidence may still be useful, but its claim ceiling has to remain limited.
Frequency is being designed to distinguish first-party execution records from independent observations. The goal is not to distrust every tool. It is to prevent an execution system from becoming its own unquestioned auditor.
That is why observation, receipts, provenance and evidence binding matter as much as authorization. The stronger claim is not “the agent says it complied.” The stronger claim is that separate evidence supports what was requested, permitted, executed and observed.
Drift belongs inside the assurance model
Authorization can be correct at one moment and stale a moment later. Arguments change. Resources change. Credentials rotate. A dependency changes behavior. The environment exposes a new side effect. A policy decision can remain syntactically valid while the thing being executed no longer matches the state that justified it.
Frequency treats this as drift rather than merely an error condition. Intended state, authorized state and observed state can diverge. That divergence should become evidence, not disappear into a generic failure message.
Where MCP fits
Model Context Protocol makes this problem especially visible because it gives agents a standard way to discover and invoke tools. That is valuable, but discovery and invocation are not the same thing as execution assurance.
An MCP tool definition can describe what a tool is called and how to invoke it. Assurance has to ask additional questions: What authority becomes reachable behind that invocation? What external state can change? Which credentials are in play? Did the executed action remain bound to the action that was approved? What independently observable evidence exists afterward?
Frequency Agent Execution Assurance is intended to sit around that boundary rather than replace MCP itself.
MCP Lens is related, but it is not the same product
MCP Lens comes from the same family of problems, but it solves a different part of them.
MCP Lens is the inspection surface: help a person understand an MCP server, its tools, declared behavior, security-relevant metadata, potential mutations, capability exposure and evidence gaps without having to manually reconstruct the whole surface.
Frequency Agent Execution Assurance is the execution-assurance layer: reason about authority at action time, constrain the execution boundary, observe what actually happened, detect drift, and preserve evidence that supports bounded claims.
The simplest distinction is this: MCP Lens helps you see the surface. Frequency Agent Execution Assurance helps establish what happened when an agent crossed it.
Why the combination is more useful than either alone
Inspection without execution evidence can tell us what might happen but not what did happen. Execution evidence without a clear inspection surface can make technically correct receipts difficult for people to understand.
Together, the two directions create a more complete workflow. MCP Lens can make the exposed MCP surface legible before use. Frequency can evaluate the actual authority path around an action. Independent observation can capture resulting state. Receipts can preserve what the evidence supports. A later reviewer can compare the expected and observed paths instead of trusting a single success flag.
That combination is useful for developers, agent platforms, security teams, tool marketplaces and organizations that need to adopt agents without turning every integration into an opaque trust decision.
The claim has to remain smaller than the evidence
This is also why I am deliberately avoiding claims such as “Frequency makes agents safe” or “Frequency secures MCP.” Those statements are broader than a real assurance system can establish.
A more defensible claim is narrower: Frequency is being built to provide an independent execution-assurance layer around agent actions, preserving distinctions between requested authority, policy, effective capability, execution, observation, drift and evidence.
If a required observation is missing, the result should be NOT VERIFIED rather than silently upgraded into confidence. If evidence only proves one boundary, the receipt should not imply proof of the whole system.
What I want this integration to become
The commercial direction is a reusable integration rather than a one-off adapter: a thin boundary that agent platforms, MCP environments, developer tools and assurance marketplaces can call without exposing Frequency’s proprietary core.
The public integration surface can remain simple: normalized action requests, policy decisions, execution-bound receipts, observation evidence, drift findings and verification results. Internally, Frequency can keep the deeper capability, authority and evidence machinery behind that contract.
That separation matters both for security and for product design. Customers should be able to verify what the integration promises without receiving the private machinery that produces every decision.
From “the tool ran” to “this is what we can prove”
The direction is not to add another dashboard full of trust scores. It is to make execution boundaries harder to blur.
When an agent acts, I want the system to be able to answer a sequence of concrete questions: What was requested? What was authorized? What was effectively reachable? What crossed the boundary? What changed? What was independently observed? Did anything drift? What evidence survives? What claim does that evidence actually justify?
That is the difference between recording activity and building assurance around execution.
Frequency Agent Execution Assurance is an attempt to move agent systems from permission toward proof — without pretending that proof exists where the evidence stops.