End-user identity

DefenseClaw attributes hook activity and per-profile AI inventory to the endpoint account that produced it. This matters on shared endpoints, where the gateway's service account is not the person running the agent.

An absent field means DefenseClaw could not establish it safely. Do not infer id_kind from an identifier's shape, and do not build an email from an account name.

The directory fields come only from the operating system; DefenseClaw never calls an identity provider. See How DefenseClaw knows who a user is and Identity and authentication. The Secure Client profile emits none of the directory, session, agent identity or profile attributes.

Attribution, not authorization

Hooks run in the interactive user's session, read the account from the operating system, and send it to the loopback gateway as X-DefenseClaw-User-Id and X-DefenseClaw-User-Name. Those headers, and a user named in a hook payload, are claims. On the routes below the gateway ignores the claim and names the user it authenticated, so a forged header cannot re-attribute a record.

A request that proves nothing has no verified user. Application fields such as an X-User-Id header or a body user are recorded as a label, without id_kind, and only when no user was verified. They never choose a guardrail profile.

Join hook activity to inventory

Hook lifecycle records carry identity in the agent.lifecycle, tool.activity and guardrail.evaluation buckets. Findings and scan verdicts of an inspected request carry it in security.finding and asset.scan. Per-profile MCP inventory carries it in ai.discovery.

To follow one agent across sessions, join on defenseclaw.agent.identity.id. Join on user.id only after checking defenseclaw.user.id_kind; never join a POSIX uid to a Windows SID. In managed enterprise mode the gateway runs as a service identity, so inventory takes the owner from each profile directory's file ownership or token-bound Windows Known Folders.

Optional connector email

Email is off by default and has no CLI or TUI switch. After you review the privacy impact, add this to ~/.defenseclaw/config.yaml and run defenseclaw config validate:

config_version: 9
ai_discovery:
  include_user_email: true

A running gateway applies it on the next reload. On a managed deployment the administrator edits the machine configuration.

On a managed host the hook guardian reads each enrolled account's own profile; you do not list profiles. An address never goes on a record without a user or on another account's record. A file the reader cannot safely open (a link out of the profile, or any link on Windows) gives no address and a named include_user_email warning in the hook guardian log (C:\ProgramData\Cisco\DefenseClaw\logs\guardian\hook-guardian.log on Windows). A per-user gateway does not attach these addresses to AI discovery rows. To get a connector email, join a hook event to the latest ai_component.observed with the same user.id; it is reported once per discovery cycle.

Optional principal

No record carries defenseclaw.user.principal or defenseclaw.session.kerberos_principal unless you opt in. The domain, directory, source and assurance are sent either way.

config_version: 9
ai_discovery:
  include_user_principal: true

The option applies to the whole gateway. To send principals to a trusted local Loki but not to a SaaS destination such as Galileo, turn it on and give the other destination the strict profile.

The option governs the two principal attributes only. On a Linux host joined with SSSD fully qualified names (use_fully_qualified_names = true), the home directory is /home/alice@corp.example.com, so any record that contains a home-directory path contains the UPN whatever this option says. That includes the rule-pack directory of a hook decision, health errors, AI discovery roots and defenseclaw-gateway audit export. Paths are the path field class: sensitive and content hash them, strict removes them, none keeps them. Free text is not path-aware: a command or prompt that names the home directory keeps it under sensitive, which detects emails but not an account name in a path; content and strict replace or remove that text.

Every redaction profile preserves defenseclaw.user.name. Except under the Secure Client integration, that is the bare account name (alice) on every record, IDE plugin records included. The qualified form alice@corp.example.com is only the principal, which strict removes. If a destination must not receive even the bare account name, do not send it user-attributed telemetry: keep that route on a trusted destination or disable the export. See Redaction.

See AI discovery for profile inventory and the IDE plugin inventory.