Audit and Deny Diagnostics
Audit and Deny Diagnostics
Section titled “Audit and Deny Diagnostics”Investigation in V1 is metadata-first. Audit search, Admin Activity, and deny diagnostics explain governed decisions without returning raw request bodies, response bodies, prompts, payloads, credential material, raw headers, cookies, or secret-bearing refs.
Audience
Section titled “Audience”- Security reviewers tracing a governed call.
- Operators explaining why a tool was hidden or denied.
- Support engineers moving from request ID to safe remediation fields.
What is this?
Section titled “What is this?”This page covers three related surfaces:
- Audit search: broad metadata search for tool calls, policy decisions, credentials, sessions, API adapter calls, admin changes, and revocations.
- Admin Activity: curated admin-action read model for
/investigate/admin-activity. - Deny diagnostics: one remediation-ready bundle for a denied request, audit event, or explicit metadata context.
When do I use it?
Section titled “When do I use it?”Use audit search when you know event fields or a request ID. Use Admin Activity when you are reviewing control-plane changes. Use deny diagnostics when a reader needs to explain a denial without exposing payloads or secrets.
What happens?
Section titled “What happens?”Audit and export records may include event IDs, timestamps, actor IDs, server IDs, API source IDs, tool IDs, client session IDs, request IDs, policy version, credential mode, redaction status, outcome, and reason codes.
Admin Activity list/detail requires audit.read for the caller’s tenant and environment scope. It returns action type, actor, resource, outcome, safe diff summary, metadata hash, and related links.
Deny diagnostics requires deny_diagnostics:read and exactly one lookup selector:
- denied request ID;
- audit event ID;
- explicit context for a support form when no retained bundle exists.
The diagnostic bundle can include policy version, matched deny rule, missing allow, client surface state, environment mismatch, approval state, credential binding state, connector route state, schema validation failure, related IDs, permissions, source projections, and suggested remediation.
What can go wrong?
Section titled “What can go wrong?”- Permission denied returns a safe
403envelope with required action. - Unknown, stale, cross-tenant, or cross-environment selectors return
404so the API does not confirm another scope’s request IDs. - Empty or ambiguous lookup returns
400 deny_diagnostics_lookup_required. - Diagnostics are not a policy playground, payload inspector, prompt viewer, or secret dump.
- If a public page needs a raw payload to explain behavior, the page is wrong. Use IDs, reason codes, source projections, and metadata-only fields.
Source truth
Section titled “Source truth”- contracts/events/audit-event.schema.json
- contracts/jsonschema/policy-simulation.schema.json
- contracts/openapi/admin-api.yaml
- Read Identity, Policy, Credentials for the fields that drive denial.
- Read Register an MCP Server for approval and catalog visibility failures.
- Read Troubleshooting for operator fail-closed actions.
- Read Security Review for the no-secret rule.
Type set in Geist, Source Serif 4, and Departure Mono.