PASS and BLOCK events

AgentKeeper records different event types for different reasons. The most common enterprise confusion is seeing BLOCK events but not PASS events.

The short version: BLOCK events log regardless. PASS events require full tool-call logging for the applicable runtime policy.

Expected behavior

Event	Logged by default	Why
BLOCK	Yes	A blocked action is a security decision and must be auditable.
WARN	Yes	A warning is a security decision that needs review.
PASS	Only when full tool-call logging is enabled	Benign tool calls can be high volume, so admins choose whether to keep the full audit trail.
System	Yes	Setup, registration, and self-test events prove install state.

The setting that controls PASS

The product setting is Log All Tool Calls. When enabled, benign runtime activity can appear as PASS in Activity. When disabled, blocked and warned activity still appears, but routine allowed activity may be suppressed.

For a clean test:

Enable Log All Tool Calls in the policy surface that applies to the workstation.
Run a new tool action so the next supported runtime evaluation uses the updated policy.
Restart or refresh the agent session if the integration loads hooks at session start.
Run a benign tool call.
Filter Activity by the expected source.
Confirm the event appears as PASS.

Cowork-specific expectation

Claude Desktop / Cowork should produce source cowork.

Validation sequence:

Run a benign Cowork action, such as reading a non-sensitive project file.
Confirm Activity shows PASS with source cowork.
Run a blocked action that your policy denies, such as reading a protected secret path.
Confirm Activity shows BLOCK with source cowork.

If BLOCK appears but PASS does not:

Confirm Log All Tool Calls is enabled.
Confirm you are viewing the same environment used by the install command.
Confirm the event source is cowork.
Confirm the runtime policy applying to the user did not explicitly disable full audit logging.
Run a fresh tool action after saving policy changes; old events will not be backfilled as PASS.

Claude Chat-specific expectation

Claude Chat in Claude Desktop should produce source claude_chat when the Gateway identifies the Chat surface, or Gateway-routed MCP activity for older Gateway builds.

Validation sequence:

Start AgentKeeper Gateway.
Fully restart Claude Desktop.
Ask Claude Chat to use a configured MCP tool.
Confirm Activity shows PASS for the Chat or Gateway MCP source.
Configure a temporary policy that blocks a low-risk test MCP server or tool.
Ask Claude Chat to use that blocked tool.
Confirm Activity shows BLOCK for the same workstation.

If Gateway check-in appears but Chat activity does not, confirm claude_desktop_config.json points Claude Desktop at AgentKeeper Gateway and that Gateway is running in the same user profile.

Why system events are not enough

A system event proves that the workstation or installer reached AgentKeeper. It does not prove that the live runtime hook is firing.

A healthy install should show:

System or self-test event after setup.
PASS event after a benign tool action.
BLOCK event after a denied tool action.

Enterprise acceptance test

Before expanding a deployment cohort, run this test on at least one representative workstation per agent source:

Step	Action	Expected Activity row
1	Run setup or self-test	System event for the source or host
2	Run benign tool action	PASS for the expected source
3	Run blocked tool action	BLOCK for the expected source
4	Review person/group mapping	Event resolves to the intended policy audience

Do not mark a cohort complete if it only produces system events.

Was this page helpful?