fix: improve privacy cloud event summaries

[Mr-Lucky]

Summary

Improve Cloud-facing privacy event summaries while preserving the existing v1 API format.

• Report human-readable sensitive-data types and actual enforcement outcomes.
• Use fixed masks such as sk-**** and ***@*** without uploading matched values.
• Distinguish blocked events from observer-only events that could not block the model call.
• Restore privacySummary to its existing top-level wire-contract field.
• Cover credentials, private keys, and all supported PII categories.

Type

• Bug fix
• New feature / detection rule
• Refactoring
• Documentation

Testing

• npm run build passes
• npm test passes (854 passed, 1 skipped)
• Manually tested the change

Related Issues

Closes #

[github-actions]

AgentGuard PR Review

I found a few concrete issues introduced by this patch.

1. severity: high — src/runtime/redaction.ts / summarizeSensitiveData() can misclassify PII and produce incorrect counts

   • piiText.split(marker).length - 1 counts every occurrence of a fixed redaction marker in the redacted text, but the underlying redaction logic may emit the same marker for unrelated data or multiple fields in one payload. This can overcount categories and make the new privacySummary inaccurate.
   • email_address is emitted for any redacted PII marker, but the code only checks the redacted output, not the original match type, so summaries can be wrong or misleading.
   • Fix: have the PII redaction layer return structured match metadata (kind + count) and build summaries from that, instead of inferring from redacted text markers.

2. severity: medium — src/runtime/protect.ts / withFriendlySensitiveDataReason() leaks internal enforcement semantics into reasons for all relevant LLM actions

   • The patch rewrites or inserts PII_EGRESS reasons for any llm_request/llm_response or existing PII_EGRESS case, even when the original decision reason was unrelated or when the event was not actually an egress exposure. This can produce misleading audit records and mask the original security rationale.
   • Fix: only attach the friendly summary when the original decision already contains a PII-related reason, and preserve the original reason object for non-PII cases.

3. severity: medium — src/runtime/protect.ts / sensitiveDataOutcome() can report “blocked” on observer-only or unsupported paths

   • The outcome depends on enforcementStatus, but protectAction() computes enforcementStatus from action.enforcementStatus ?? enforcementStatusFor(action, decision). If a caller omits or mislabels this field, the code may claim a block/hold even when the host could not enforce it.
   • Fix: derive the outcome from the actual enforceable path only, and never use “blocked/held for approval” unless the runtime actually executed an enforcement action.

4. severity: low — src/runtime/protect.ts may alter the Cloud event payload shape in a way tests don’t fully cover

   • Moving privacySummary from metadata to the top-level event changes serialization behavior and may break consumers expecting the previous location, especially if buildAuditEvent() or downstream parsers only inspect metadata.privacySummary.
   • Fix: confirm the wire contract in all serializers; if compatibility is required, keep the old field location or emit both until consumers are migrated.