What AgentKeeper sees
AgentKeeper observes AI agent activity through the hook or gateway surface installed on the workstation. It does not claim visibility into actions an agent never emits, and it does not silently...
AgentKeeper observes AI agent activity through the hook or gateway surface installed on the workstation. It does not claim visibility into actions an agent never emits, and it does not silently infer unsupported activity.
Use this page to set the enterprise expectation before a rollout: what evidence is collected, where it appears, and what determines whether AgentKeeper can block before an action runs.
Runtime evidence
AgentKeeper can record these event types when the connected integration emits them:
| Evidence | Examples | Used for |
|---|---|---|
| Prompt events | prompt submit, prompt validation, session context | prompt-injection detection, audit, investigations |
| Tool calls | file read/write, shell command, web request, MCP tool | allow, warn, block, evidence retention |
| Workstation identity | hostname, source integration, version, session | fleet inventory, person mapping, setup health |
| Policy context | Base Policy, matched policy packs, detector response | explaining why an event passed, warned, or blocked |
| Redacted payload evidence | path, command argv, domain, tool name, detector reason | investigation without storing unnecessary raw content |
| Connection country | derived from the connecting IP at ingest; the raw IP is discarded and never stored | country-level only, used for the Activity world map; can be disabled per-org in Settings → Privacy |
| SaaS compliance evidence | OpenAI Compliance API, Anthropic Compliance API, provider-side audit exports | after-the-fact audit, investigations, AI Discovery, and Detector Studio surfaces |
Coverage depends on the agent. Claude Code and Cowork expose different hook surfaces. Cursor, Codex, Gemini CLI, Google Antigravity, Copilot, and Windsurf each emit different event shapes. Use Supported agents before promising a control to an enterprise team.
Compliance API connectors such as OpenAI Compliance API ingest provider-side logs after the provider has recorded the activity. They are useful for audit and investigations, but they cannot block an already-completed SaaS action.
What PASS, WARN, and BLOCK mean
| Verdict | Meaning | Activity behavior |
|---|---|---|
| PASS | The action matched policy and was allowed. | Logged when full tool-call logging is enabled for that source and policy. |
| WARN | The action was allowed, but policy or detection marked it for review. | Logged as a warning event. |
| BLOCK | The action was denied before execution where the hook supports pre-execution enforcement. | Logged even when full tool-call logging is off. |
| System | Setup, registration, self-test, or lifecycle event. | Used to prove installation health, not runtime policy coverage. |
Blocked events should be visible by default. PASS events depend on full audit logging because high-volume benign activity can otherwise overwhelm the Activity stream.
Prompt Vault modes
Prompt retention is governed by Prompt Vault. Organizations can choose:
| Mode | What normal evidence shows |
|---|---|
| Visible Capture | Raw prompts can appear in event context, Activity, OTLP prompt previews, findings, and investigations. |
| Sealed Evidence | Raw prompts are encrypted in Prompt Vault. Normal evidence shows metadata and a reveal control that requires owner or admin access plus a reason. |
| Promptless | Raw prompts are not retained. Evidence shows that a prompt was evaluated, plus metadata such as length and hash. |
Detection still evaluates supported prompts in memory before retention policy is applied.
Summaries vs retained evidence
Activity tables use short summaries on purpose. Long prompts, command bodies, and tool payloads would make fleet views unreadable, so rows show bounded text such as the first part of a prompt or the target file path.
Open an event to see retained evidence:
| Setting | What it controls | Enforcement impact |
|---|---|---|
| Log all tool calls | Whether benign PASS events are written to Activity. WARN and BLOCK events are still recorded. | None. Policies still evaluate every supported hook event. |
| Prompt Vault | Whether prompts are visible, sealed behind audited reveal, or never retained. | None. Prompt detectors still evaluate the full prompt before retention settings are applied. |
| Log tool parameters | Whether tool arguments and payload detail can be retained for investigation. Short summaries may still appear unless the source only emits redacted metadata. | None. Runtime policy still receives the hook payload needed to allow, warn, or block. |
| Deep capture | Opt-in richer payload retention for supported sources. Oversized payloads are bounded and marked as truncated. | None. This is an evidence-retention setting, not an enforcement setting. |
If a prompt looks short in a table, that is expected. If the event detail says full prompt, AgentKeeper retained the full prompt body subject to the retention limit. If it says summary only or prompt logging disabled, the control worked but the full text was not stored.
What AgentKeeper does not see
AgentKeeper does not see activity that bypasses the installed hook or gateway. Examples:
- A developer runs a tool outside the connected agent.
- An IDE version does not emit a given hook event.
- Claude Desktop has a Cowork session, but the local Cowork hook was not loaded after restart.
- MCP traffic goes directly to an MCP server instead of through the configured gateway.
- A SaaS provider action is not included in that provider's Compliance API export or is outside its retention window.
- An install points to sandbox while the admin is reviewing production, or the reverse.
When visibility is missing, start with Setup health, then use Missing activity events.
Where evidence appears
- Activity shows runtime verdicts, source, host, tool, reason, and session context.
- Workstations shows registered hosts, source integrations, versions, and recent activity.
- People ties workstation evidence to accountable users when identity resolution succeeds.
- Policy Packs explains why a group received additional runtime controls beyond Base Policy.
- Investigations reconstructs related events across a session when an event needs review.
Enterprise rollout rule
Do not treat a workstation as protected until all three checks pass:
- A system or self-test event appears for the expected source.
- A benign runtime action appears as PASS when full tool-call logging is enabled.
- A known blocked runtime action appears as BLOCK.
If any check fails, the install may be present but not operational for that source.