> For the complete documentation index, see [llms.txt](https://docs.strongdm.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.strongdm.com/ai/ai-attribution.md). # AI Attribution How AI agent access can be detected in StrongDM resource connections and queries and how to write policies to implement finer-grained controls on agentic access. {% hint style="warning" %} This feature is currently in a closed-access tech preview. Functionality and documentation may change. Contact StrongDM for more information. {% endhint %} ## Overview Actions performed on resources via StrongDM can be audited to check whether or not they were initiated by an agent. These agentic initiators are able to be detected if the agent is one that StrongDM supports for detection. The information available about the initiator of any given action can be used in policy controls to further define allowed actions in various circumstances. ## Identify AI-initiated Access When a connection is opened through the StrongDM client, the client inspects the connection and matches against a fixed catalog of known AI tools, including Claude Code, Claude Desktop, Codex (Desktop and CLI), Cursor, ChatGPT Desktop, and Gemini CLI. The result is attached to the session as an **initiator** record. | Field | Values | Meaning | | -------------------- | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | `initiator.ai_agent` | `claude-code`, `claude-desktop`, `codex-desktop`, `cursor` | Detected AI tool | | `initiator.trusted` | `true`, `false` | Whether the tool's identity was verified against its code signature, rather than identified heuristically | | `initiator.type` | `unknown` | An error during detection caused an inability to ascertain whether an AI tool was used or not | The authenticated user remains the actor on the log entry; the initiator record adds the AI-tool context, so you can answer both "on whose behalf" the action was performed and "what tool acted on their behalf." The `trusted` indicator being `true` means that the identity was confirmed cryptographically or by the operating system. The `false` value only indicates that it was identified by a weaker signal that could potentially be imitated. The availability of these confirmable signals vary from platform to platform. Due to this limitation, signals from Linux platforms and some versions of Windows do not receive Trusted status. {% hint style="info" %} AI agent identification and the related policy controls are enabled per organization during the technical preview. Contact StrongDM to enable them for your organization. {% endhint %} {% hint style="warning" %} AI detection signals cannot be tampered with in transit, but they originate from the client, so treat them as strong attribution rather than as unforgeable identities. Pair these signals with the client hardening described below for managed fleets. On platforms where the tool's binary signature cannot be verified, identification is heuristic and `initiator.trusted` is `false`. {% endhint %} ### Initiator Details in Logs Initiator details appear in the Admin UI log views for AI-initiated sessions, and logs can be filtered by initiator type and by specific AI agent. In the **Queries** page, in the entries for individual queries where AI agents were detected, badges in the upper left show the name of the agent (such as "Claude Code") and "Trusted" if the agent is trusted. A red "Unknown" badge is shown if detection fails. ## Supported Agents The agents that are currently supported by this feature are listed here. The "Name" value is the one that will be seen in logs. The "Trusted" value being `true` only means that the identity can be confirmed cryptographically or by the operating system. A `false` value only indicates that it is currently identified by a weaker signal that potentially could be imitated. ### Windows | Tool | Name | Install Method | Trusted | | -------------------------- | ---------------- | ---------------------------------------------------------- | ------- | | ChatGPT Desktop (app) | chatgpt-desktop | Microsoft Store (MSIX) | Yes | | Claude Code (CLI) | claude-code | native installer (preferred method according to Anthropic) | Yes | | Claude Code (CLI) | claude-code | npm (`npm install -g @anthropic-ai/claude-code`) | Yes | | Claude Code (CLI) | claude-code | winget (`winget install Anthropic.ClaudeCode`) | Yes | | Claude Desktop | claude-desktop | installer | Yes | | Codex Desktop (app) | codex-desktop | Microsoft Store (MSIX) | Yes | | Codex (CLI) | codex-cli | npm | No | | Codex (CLI) | codex-cli | standalone | No | | Codex (CLI) | codex-cli | winget/native | No | | Cursor (CLI) | cursor-cli | native | No | | Cursor (editor) | cursor | installer | Yes | | Google Antigravity (CLI) | antigravity-cli | standalone (`%LOCALAPPDATA%\agy\bin`) | No | | Google Antigravity (CLI) | antigravity-cli | winget | No | | Google Antigravity Desktop | antigravity | Installer | No | | Google Gemini (CLI) | gemini-cli | npm (shared `node.exe`) | No | | OpenCode CLI | opencode | native | No | | OpenCode CLI | opencode | npm | No | | OpenCode CLI | opencode | winget | No | | OpenCode Desktop | opencode-desktop | installer | Yes | ### macOS | Tool | Name | Install Method | Trusted | | ------------------------------ | --------------- | --------------------------------- | ------------ | | ChatGPT Desktop (app) | chatgpt-desktop | — | Not detected | | Claude Code (CLI) | claude-code | brew | Yes | | Claude Code (CLI) | claude-code | native | Yes | | Claude Code (CLI) | claude-code | npm (`@anthropic-ai/claude-code`) | Yes | | Claude Desktop (app) | claude-desktop | app bundle | Yes | | Codex (CLI) | codex-cli | brew | Yes | | Codex (CLI) | codex-cli | native | Yes | | Codex (CLI) | codex-cli | npm | Yes | | Codex Desktop | — | — | Not detected | | Cursor (CLI) | cursor-cli | brew | No | | Cursor (CLI) | cursor-cli | native | No | | Cursor (editor) | — | — | Not detected | | Google Antigravity (CLI) (agy) | antigravity-cli | brew | Yes | | Google Antigravity (CLI) (agy) | antigravity-cli | standalone (`~/.local/bin/agy`) | Yes | | Google Antigravity Desktop | antigravity | native | Yes | | Google Gemini (CLI) | gemini-cli | brew | Yes | | Google Gemini (CLI) | gemini-cli | npm (shared `node`) | No | | OpenCode CLI | opencode | brew | No | | OpenCode CLI | opencode | npm | No | | OpenCode CLI | opencode | standalone (`~/.opencode/bin`) | No | | OpenCode Desktop | — | — | Not tested | ### Linux Linux detection is structurally heuristic-only: there is no signature or certificate to verify and no file hash is computed, so `signer.validated` is always false and no Linux agent can be `Trusted = Yes`. | Tool | Name | Install Method | Trusted | | -------------------------- | ----------- | ---------------------------------- | ------------- | | ChatGPT Desktop (app) | — | — | — | | Claude Code (CLI) | claude-code | native | No | | Claude Code (CLI) | claude-code | npm (`@anthropic-ai/claude-code`) | No | | Claude Desktop (app) | — | — | — | | Codex Desktop | — | — | — | | Codex (CLI) | codex-cli | npm | No | | Codex (CLI) | codex-cli | standalone | No | | Cursor (editor) | — | — | Not cataloged | | Cursor (CLI) | cursor-cli | native | No | | Google Antigravity (CLI) | — | standalone | Not detected | | Google Antigravity Desktop | — | — | Not tested | | Google Gemini (CLI) | gemini-cli | npm (shared `node`) | No | | OpenCode CLI | opencode | npm (`opencode-ai`, native binary) | No | | OpenCode CLI | opencode | standalone (`~/.opencode/bin`) | No | | OpenCode Desktop | — | — | Not tested | ## Policy Controls for AI Agents With AI agent identification enabled, the initiator record is available as a condition in [policies](https://github.com/strongdm/docs/tree/main/gitbook-content/admin/access/access/policies/README.md), alongside the existing principal, action, and resource dimensions. This lets you control AI agent access independently of the user's broader entitlements: the user keeps their access, while the AI path is restricted. Initiator conditions are evaluated when a session is established, and active sessions are re-evaluated continuously, so tightening a policy also terminates in-flight AI agent sessions that no longer comply. In the policy builder, initiator conditions are available in the **when** clause. The following examples show common patterns in Cedar. Block access for all AI agents that can be detected organization-wide: ```cedar forbid ( principal, action, resource ) when { context has initiator && context.initiator.ai_agent != "" }; ``` Block AI agents from accessing production-tagged resources, without affecting the same users' direct access: ```cedar forbid ( principal, action, resource ) when { context has initiator && context.initiator.ai_agent != "" && resource.hasTag("env") && resource.getTag("env") == "prod" }; ``` Block the AI path for a specific group whose members hold broad access; the SREs keep their direct production access, but AI agents that we recognize running under their identity are denied: ```cedar forbid ( principal in StrongDM::Role::"SREs", action, resource ) when { context has initiator && context.initiator.ai_agent != "" && resource.hasTag("sensitive") }; ``` Allow only specific, signature-verified AI tools; block all others that we recognize: ```cedar forbid ( principal, action, resource ) when { context has initiator && context.initiator.ai_agent != "" && !(context.initiator.trusted == true && ["claude-code", "claude-desktop"].contains(context.initiator.ai_agent)) }; ``` {% hint style="info" %} If an agent from the supported list is detected, `context.initiator.ai_agent` is filled with a value for that agent type. If no known agent is detected, this could mean that the initiator was an unknown agent type, or it could mean that it was a human or machine principal. In those cases, `ai_agent` is empty. And if the value is empty due to detection failing for some reason, `context.initiator.type` will also be set to `unknown`. {% endhint %} For general policy authoring guidance, see [Policy Creation](https://github.com/strongdm/docs/tree/main/gitbook-content/admin/access/access/policies/policy-creation.md) and [Policy Use Cases](https://github.com/strongdm/docs/tree/main/gitbook-content/admin/access/access/policies/policy-use-cases.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.strongdm.com/ai/ai-attribution.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.