Discover your AI tools. See what's actually verified.

A configuration file can show that hooks are installed. A Gateway URL can show that routing is configured. Neither proves that a tool's actions or model requests are passing through those controls.

That distinction is central to Conduct Guard Discovery.

Start with one command

conduct guard discover

Discovery checks supported local tools, reports configuration and observed hook activity, and checks configured Conduct Gateway connections. Here is an actual example:

Gateway check uses the CLI credential; it does not prove this tool's inference traffic.

Discovery: 4 local findings (complete)
  claude-code [installed] | hooks: observed | gateway: unverified
  codex [running] | hooks: observed | gateway: unavailable
  cursor [running] | hooks: unverified | gateway: unverified
  copilot-cli [running] | hooks: configured | gateway: unverified
Configuration is not proof of enforcement. Run conduct guard sync for supported tool setup.

This is not an "everything is protected" badge. It is a breakdown of what Conduct found and what evidence is available.

Read the evidence, not just the configuration

Each finding separates three questions:

Detection

Was the tool detected as installed or running at scan time?

Hooks

Are hooks configured, or has recent installation-linked hook activity been observed?

Gateway

Is routing configured, and could a supported connection check verify authentication and connectivity?

• Claude Code: Recent hook activity was observed. Gateway routing remains unverified.
• Codex: The tool was running and hook activity was observed. The Gateway connection check was unavailable, so it did not establish a verified connection.
• Cursor: The tool was running, but hook and Gateway evidence remain unverified.
• Copilot CLI: Hooks are configured, but configuration alone does not show that a hook has executed.

"Complete" describes the discovery scan, not complete governance coverage. Observed hook activity is evidence of a reported event, not proof of continuous enforcement.

Gateway checks are included

Conduct CLI 0.14.15 includes Gateway connection verification in discovery by default.

For supported, configured Conduct endpoints, the check uses the CLI's Conduct credential to make a model-list request. It does not send prompts, make paid inference calls, or test an upstream provider API key.

A successful check establishes connectivity with that credential. It does not prove that the discovered tool sends its inference traffic through Gateway. These checks do not verify external gateways such as LiteLLM or OpenRouter.

To skip the connection check:

conduct guard discover --no-verify-gateway

How this helps companies

When teams use different AI coding tools, an approved-tools list does not tell you what is installed, what is running, or which controls have actually reported activity. Discovery gives engineering, platform, and security teams a shared starting point for those questions.

• Make tool adoption visible. Identify supported tools on scanned devices and review uploaded findings in the workspace inventory. Device and installation identity help teams distinguish separate installations from repeated detections. This is visibility into participating devices, not an automatic scan of the entire company network.
• Prioritize setup gaps. Separate tools with observed hook activity from those that are only configured or remain unverified. Teams can investigate missing evidence instead of treating every installation as protected, or asking everyone to repeat setup unnecessarily.
• Make developer onboarding repeatable. Use the same sequence for each supported tool: sync its setup, restart it, perform a tool action, and check discovery. That gives developers and platform teams an observable checkpoint beyond "I installed it."
• Narrow troubleshooting. Hook activity and Gateway connectivity are separate signals. A tool can have working hooks while its Gateway check is unavailable. Keeping those signals separate helps teams investigate the relevant configuration or connection rather than reinstalling everything.
• Support evidence-based security reviews. Installation details, timestamps, and links to recorded activity give reviewers concrete evidence to inspect. They can distinguish a configured control from an observed event and identify what still needs validation. Discovery alone is not a compliance certification or proof that every action was governed.

A practical rollout example

Consider an engineering team using Claude Code, Codex, Cursor, and Copilot CLI. Start with a pilot group of developer devices and review their discovery findings together. For a tool with configured hooks but no observed activity, perform a test action and check again. For an unavailable Gateway check, investigate connectivity and authentication separately.

Use those findings to assign follow-up work and repeat the checks after setup changes. The benefit is a clearer rollout review: which installations have evidence, which need attention, and which claims the available evidence cannot support.

Turn findings into next steps

For supported tools that need setup, run:

conduct guard sync

Restart the affected tool, perform a simple tool action, then run discovery again. Look for hook status to move from configured to observed.

In Conduct's Guard → Agents Discovered view, inspect installation evidence, timestamps, and setup guidance, then open Flight Recorder to investigate recorded activity.

If Gateway remains unavailable or unverified, investigate that separately. Reinstalling hooks is not proof that model routing works.

Configuration is a starting point

AI governance needs more than an inventory of installed tools. It needs a clear distinction between what was discovered, what is configured, what has been observed, and what still needs verification.

Conduct Guard Discovery makes those distinctions visible, without turning missing evidence into a claim of protection.

Start with conduct guard discover. See what's known. Verify what's next.

Install the Conduct CLI