Privacy & Governance
Coding-agent sessions can carry sensitive material - prompts, file contents, proprietary code. Shield360 gives you control over how much of that gets captured, and applies redaction regardless of the mode you choose.
Content capture modes
Section titled “Content capture modes”The organization’s collection policy sets what lands on spans, and each machine can narrow it:
| Mode | Identifiers | Tool names + paths | File diffs / message bodies |
|---|---|---|---|
minimal | ✅ | ❌ | ❌ |
metadata_only | ✅ | ✅ | ❌ |
full | ✅ | ✅ | ✅ |
Data retention caps the level. The hooks send message bodies and file diffs only when the organization stores them, under Store prompt and response content or Store tool-call arguments, results and code. Both are off by default, so out of the box coding agents send metadata_only and no prompt is stored. Turn one of them on to get the full trace detail view.
The organization’s administrator can lower the level further under Settings → Collection & deployment → Collection policy → Coding-agent content, and for one person from that person’s page. See Collection policy. Choose metadata_only for a team whose prompts may carry confidential material even where other teams’ are stored, or minimal if you only need cost and activity dashboards and not the per-event timeline.
A machine’s own setting (shield360 configure --content-capture or SHIELD360_CODING_CONTENT_CAPTURE; see Setup & Configure) can narrow the level further but can’t widen it. The hooks use the strictest of the organization’s level, the person’s narrowing and the local setting. The platform removes bodies above the level again on ingest, in case a machine sends them anyway. Sessions captured under minimal or metadata_only show a banner in their session detail view explaining what wasn’t recorded.
Redaction
Section titled “Redaction”Two redaction tiers run on every export, regardless of capture mode:
- Tier 1 - a token-pattern scrubber that always runs, stripping API keys, tokens, and known secret patterns without breaking JSON structure.
- Tier 2 - a body-scope scrubber, active only in
fullmode, that applies the same scrubbing to file diffs and message bodies before they’re exported.
The active capture mode is stamped as a resource attribute (coding_agent.content_capture_mode) on every span, so you can audit what a given session was recorded under after the fact.
What agents may change
Section titled “What agents may change”Beyond what leaves the machine, the organization’s enforcement policy can say what an agent may change. Under Protect → Policies → Coding agents → What coding agents may change:
- Protected paths: globs relative to the repository (
src/payments/**,**/*.tf,infra). Each rule either records the edit or refuses it, and applies to every agent edit or only to edits the agent applies without a person reviewing them (Claude Code’sacceptEditsandbypassPermissions, Codex’s full-auto). A reason travels with the rule and is shown to the developer and to the agent, which is told not to try another way. - Expensive patterns: a query inside a loop,
SELECT *, a query with no limit, a whole file read into memory, a list call without pagination, a retry loop without backoff, logging in a loop. The same shapes the repository walk reports, caught in the new text before it is written.
The rules are evaluated by the hooks on the developer’s machine at the moment of the edit, from the policy the collector caches, so the answer is immediate and identical everywhere. Claude Code, Codex, Gemini CLI, Copilot CLI and OpenCode can be refused; Cursor reports edits after the fact, so on Cursor these rules record and never block. Each decision is recorded as a guard event on the session, kind and path only, never the text.
When the policy can’t be read
Section titled “When the policy can’t be read”The guard reads the policy the collector caches on the machine. If that copy is missing or corrupt, prompts are allowed by default. To refuse them instead, turn on Block when the policy is unavailable on the Sensitive data tab of the enforcement policy. How the guard behaves then is described in the collection policy.
Trace Governance Passport
Section titled “Trace Governance Passport”Coding-agent sessions also appear in the product Trace Governance view: open a session or request trace → hierarchy explorer → Governance tab. That report surfaces permission mode, capture mode, classification, agent loops, and related findings, with optional JSON passport export for evidence packages. See Trace Governance.
Attribution safeguards
Section titled “Attribution safeguards”Per-user attribution is capped by a cohort floor: viewer-tier accounts cannot see per-user metrics for a user with fewer than five sessions in the selected window. Admin-tier accounts see the full breakdown. This prevents singling out an individual developer from a small sample on the Users tab.
Threat model
Section titled “Threat model”The shield360 CLI runs on the developer’s own machine, alongside the coding agent, and authenticates to your collector with an org-scoped API key - the header proves the event came from a machine your org authorized, not that a specific event wasn’t spoofed by anyone with shell access on that machine. In practice this is the same trust boundary as any other locally-run developer tool: someone who can run the hook can equally well run any other process under their own user. If you need a stricter guarantee for an untrusted developer fleet, front the OTLP endpoint with a collector that validates the authenticated key’s owner against the event’s user attribute, or disable the hook tier entirely and rely on a vendor’s native OTel exporter (where the vendor signs its own egress) instead.
Troubleshooting
Diagnose missing rows, silent hooks, or a stale database config