A Valid Agent Can Still Use the Wrong Tool
A valid agent identity says who is calling. It does not prove that the tool, exact version, assignment, or requested invocation is approved.
Why Agent Identity Does Not Approve a Tool
An authenticated agent can hold a valid mandate and still call the wrong tool. The package may be unassessed, the approved version may have changed, the tool may not be assigned to that agent, or the requested arguments may violate current policy.
The control question is therefore larger than 'who is this agent?' It is 'may this agent invoke this exact tool version, with these arguments, under this policy, right now?'
A Bounded Example
A purchasing agent is authorized to buy a $0.01 API response. Its identity and spending mandate are valid. The agent then calls a local payment adapter whose bytes differ from the version reviewed yesterday.
The payment amount remains in scope, but the execution path has changed. Allowing the transaction based on identity alone would skip the tool-integrity question. The governed call should stop until the changed artifact is assessed and approved.
Agent Passport and Tool Passport Solve Different Problems
An Agent Passport carries identity, principal, mandate, lifecycle, and available reputation context for the non-human actor. A Tool Passport identifies an approved software artifact and exact version. Neither substitutes for the other.
The assignment between them is also separate. A valid tool can exist without being assigned to a particular agent, and a valid agent can exist without permission to use that tool.
The Exact-Version Approval Chain
- 1. Submit the artifact. Detonate receives one supported submitted artifact for assessment.
- 2. Assess the submitted version. The report describes evidence about those exact bytes. A passing assessment is not a claim that the software is vulnerability-free.
- 3. Review the evidence. An independent approval step decides whether the findings and intended scope are acceptable.
- 4. Issue the FLINT Stamp and Tool Passport. The approved digest, version, and scope receive durable identifiers.
- 5. Assign the tool to the agent. The relationship states which agent may request the approved tool.
- 6. Apply current policy at invocation. Command evaluates the assignment, revocation state, digest, arguments, and policy before the governed call.
Changed bytes produce a different digest. The new artifact requires reassessment and reapproval before it can replace the approved version on the governed path.
Assessment Is Evidence, Not Permission
Detonate assesses one submitted artifact in isolation. The report can identify static, sandbox, dependency, and red-team findings for that version. It does not grant a principal's authority, assign the tool to an agent, or approve every use of the software.
Permission emerges from the full chain: assessment, review, Stamp, Tool Passport, assignment, current policy, and the invocation request. Removing any link turns evidence into an assumption.
What FLINT Command Covers Today
FLINT Command is a managed design-partner pilot for one scoped Linux workflow. Supported calls pass through a governed control point that checks the approved tool version, assignment, revocation state, and policy before execution.
Command does not monitor the full host, approve arbitrary customer tools, cover Windows or macOS, or provide a self-serve SDK today. Revocation affects subsequent online gateway calls that check current state. It cannot stop activity routed outside the governed path.
Keep the 3 Evidence Records Separate
A Verify record captures the transaction authority decision. A signed Command invocation decision captures whether the approved tool call was allowed or blocked. A separately signed execution outcome records whether the allowed call later succeeded, failed, was not executed, or remained unknown.
Shared identifiers can link the chain. One record does not prove the fact observed by another. The integrating caller still enforces the transaction and invocation decisions.
Common Questions
Does a valid Agent Passport approve every tool?
No. Agent identity and tool approval are separate controls.
Does a clean assessment mean the tool is safe?
No. It records findings for one submitted version. It does not prove the absence of vulnerabilities or grant permission to use the tool.
Why does the digest matter?
The digest binds approval to exact bytes. Changed bytes are a new version that needs a new assessment and approval.
Can revocation stop a running process?
Not by itself. It can block subsequent governed calls that check current revocation state.
Approve the agent and the exact tool version as separate subjects. Then enforce their relationship at the invocation that matters.
Primary Sources
Related Academy Briefs
Get in touch
If you are building on agentic payment rails and want to talk through how FLINT fits your stack, reach out directly.
contact@flint.network