Agent observability starts with a simple distinction: an action request, an executed handler, and a verified result are three different events. A useful audit trail records all three, together with the state and permission boundary that shaped the decision.
The current WebMCP draft does not provide a portable agent-identity or attribution signal that applications can treat as authoritative. Do not build an audit model around the obsolete SubmitEvent.agentInvoked property or infer identity from a user-agent string. Instrument the application and tool boundary directly.
The four-stage audit loop
1. State observed
Record the minimum context needed to explain the action:
- document or screen identifier;
- state version or observation timestamp;
- relevant resource identifiers;
- visible or exposed target identifiers;
- signed-in user and permission scope.
Avoid storing a full page dump or sensitive model context when a few identifiers and hashes are enough.
2. Guidance or action proposed
Record what the agent attempted to help with:
- requested job;
- selected tool or guidance target;
- supplied arguments;
- whether user confirmation was required;
- permission decision and policy version.
If the experience highlights or tours visible interface elements, log the target identifiers separately from action execution.
3. Supported action invoked
Record the execution event:
- tool name and version;
- normalized arguments;
- handler start and end time;
- application and server authorization result;
- side effects attempted;
- stable failure code when rejected.
A model selecting a tool does not mean the application accepted or completed the action.
4. Result verified
After a mutation, compare the expected postcondition with a new observation:
- expected resulting state;
- observed resulting state;
- verification method;
- matched, mismatched, or unavailable outcome;
- any recovery or user-facing clarification.
Treat “completed but not verified” as its own state.
A structured event
{
"event_type": "agent_action_audit",
"occurred_at": "2026-07-11T14:05:12Z",
"context": {
"screen_id": "record_detail",
"resource_id": "rec_4821",
"state_version": "v17",
"visible_targets": ["status_control"]
},
"request": {
"tool": "set_record_status",
"arguments": { "status": "paused" },
"confirmation_required": true,
"confirmation_received": true
},
"authorization": {
"user_id": "usr_08a7",
"policy_version": "2026-07-01",
"decision": "allow"
},
"execution": {
"outcome": "completed",
"latency_ms": 214
},
"verification": {
"expected": { "status": "paused" },
"observed": { "status": "paused" },
"outcome": "matched"
}
}Do not log raw secrets, payment details, unnecessary personal data, or unbounded page content.
Metrics that help diagnose the system
Useful operational measures include:
| Metric | What it answers |
|---|---|
| Tool selection rate | Does the agent choose an exposed action for relevant requests? |
| Authorization rejection rate | Are requests crossing permission or intent boundaries? |
| Execution failure rate | Which handlers fail after authorization? |
| Verification mismatch rate | How often does the observed state differ from the claimed result? |
| Unverified completion rate | How often can the system not inspect the result? |
| Repeated-action rate | Does the agent retry an action because the first result was unclear? |
| End-to-end latency | How long does observation through verification take? |
Set alert thresholds from your own baseline and risk model. Do not copy universal percentages from another product.
Permission and security review
For each state-changing tool, an audit should answer:
- Which user permission authorized the action?
- Did the user express sufficiently clear intent?
- Which resources were in scope?
- Did the handler attempt anything outside that scope?
- What state was observed after execution?
High-risk patterns include repeated permission probes, bulk mutations, cross-workspace identifiers, and a sequence of completed-but-unverified actions.
Separate agent audit from business analytics
An agent audit trail explains what the system attempted and whether the result was verified. It does not by itself prove productivity, adoption, conversion, or revenue impact.
Business evaluation needs a separate method with a defined cohort and comparison:
- task completion;
- time to complete the task;
- user correction or reversal;
- trust and comprehension;
- downstream commercial outcomes, when enough evidence exists.
Do not turn tool-call volume into an outcome claim.
Implementation guidance
- Create one correlation ID for observation, action, and verification events.
- Version tool schemas and permission policies.
- Preserve stable error codes alongside readable messages.
- Redact or hash parameters that are not needed for debugging.
- Define retention and access controls for the audit log.
- Test missing, delayed, and contradictory post-action observations.
How this relates to kn8
kn8 is not a WebMCP observability platform. Its own runtime can be described with bounded audit questions: what current interface state the connected host supplied, which visible target was used, which supported action was invoked, and whether the resulting state was inspected. No customer dashboard, anomaly threshold, or commercial outcome is claimed here. See the connected-interface model →
Key takeaways
- Instrument the application boundary rather than relying on an obsolete browser attribution flag.
- Record starting context, permission, execution, and verification as separate events.
- A successful handler call is not the same as a verified result.
- Keep security audit data separate from commercial outcome measurement.
- Derive thresholds from the product’s own baseline and risk.