Trust Agent AI FAQ

Product scope and promise

What is Trust Agent: AI?

Available from March 26, Trust Agent: AI is the AI Software Governance control plane designed to help organisations safely scale AI-assisted development with confidence.

What is it not?

Trust Agent: AI is not:

• a SAST scanner
• a DLP gateway
• an enforcement or blocking product

It is an observability, attribution, and governance layer.

What is the difference between AI software governance and AI code scanning?

AI code scanning analyzes code after it is written to detect vulnerabilities.

AI software governance focuses on how AI is used across the development lifecycle. It provides visibility into:

• model usage
• developer activity
• policy posture

While code analysis can be one input, governance goes further by connecting usage to risk, policy, and outcomes over time.

How does it help reduce vulnerabilities introduced by AI coding assistants?

Trust Agent: AI helps teams reduce risk by:

• improving visibility into AI usage
• highlighting out-of-policy AI usage
• supporting targeted learning for developers

It is designed to highlight what AI tools and models are used so customers can make better decisions and improve secure AI-assisted development practices over time. It should not be positioned as a standalone prevention or enforcement tool.

What AI coding environments does Trust Agent: AI support?

Trust Agent: AI supports selected AI-assisted development environments through available instrumentation surfaces.

This currently includes:

• VS Code via plugin
• broader workflows via Local Agent (Open Beta)

Coverage varies by:

• tool
• provider
• deployment model

Customers should confirm their specific setup using the compatibility matrix during onboarding.

What is GA vs Open Beta vs Prototype right now?

GA

• VS Code AI usage visibility
• AI-triggered Adaptive Learning
• MCP inventory and dashboard

Open Beta

• Local Agent for Windows and macOS
• GA soon

Prototype / Preview

• LLM Policy clickable prototype
• GA soon

What is MCP visibility in AI governance?

MCP visibility shows which MCP providers and tools are present and being used across development workflows. It helps establish a baseline inventory of the AI tooling supply chain and reduces shadow AI risk.

What is the minimum setup required for a customer to see value?

Minimum requirements:

• AI enabled for supported VS Code workflows
• organisation setup completed
• developers using supported AI tools in VS Code
• telemetry flowing

Target customer

Who is the primary admin persona? Who else benefits from the insights?

The primary user is:

• AppSec
• Product Security
• Security Admin

Secondary users include:

• security architecture
• DevSecOps / platform teams
• engineering leadership
• governance / compliance stakeholders

Customer workflow

What are the most common admin tasks by frequency?

The most common admin tasks are:

1. Enable and deploy supported instrumentation
2. Confirm telemetry is flowing
3. Review AI usage visibility
4. Review MCP inventory visibility
5. Monitor AI-triggered Adaptive Learning activity
6. Use the dashboard in leadership and governance conversations
7. Expand rollout and prepare for broader governance features
8. Set up Adaptive Learning policy

How often do we expect admins to interact with this?

• Setup is typically one-time
• Ongoing usage is usually weekly or biweekly
• Additional use often happens during:
  • governance reviews
  • rollout phases
  • audit-driven events

What changes between initial setup and ongoing steering in the UI?

Setup focuses on:

• deployment
• validation

Ongoing usage focuses on:

• monitoring trends
• reviewing insights
• supporting governance and decision-making

Coverage

What environments are covered today?

GA support focuses on VS Code workflows.

Broader coverage is available via Local Agent (Open Beta).

Customers should confirm their specific stack using the compatibility matrix.

Do you detect browser-based AI usage?

Not yet fully supported.

Coverage for browser-based AI usage is in progress and will be enabled via the Local Agent.

Can you detect AI usage outside supported IDEs and agents?

Coverage is strongest in:

• supported IDEs
• endpoint-monitored workflows

We are actively working on extending coverage through the Local Agent solution.

Do you support cloud-based or remote coding agents?

No, not today.

These require different integration approaches and are not currently supported.

Do you support local model runtimes?

Local model detection is not an officially supported capability today.

How are unknown tools handled?

Unknown or partially detected tools are classified as such.

We avoid false precision and surface them for review.

Data capture

Does Trust Agent: AI store source code or prompts?

No.

Trust Agent: AI captures observable AI usage signals and commit metadata without storing source code or prompts, preserving developer privacy while enabling enterprise governance.

Do prompts or responses leave the device?

No.

Analysis happens on the developer device, and prompts or responses are not sent to SCW services.

Does source code ever leave the device?

No.

Source code is not sent to SCW services.

Can users configure what is captured or shared today?

No configuration is required today.

Data capture is limited to what is needed for governance and reporting.

Security and privacy

What security practices are in place?

Trust Agent: AI follows Secure Code Warrior’s standard security and privacy controls.

Additional details are available through the Trust Center.

How is developer identity handled?

Activity is associated with developer identity to support governance and reporting, with data collection limited to what is necessary.

Who can access the Trust Agent: AI dashboard, and what audit logs exist for admin access?

Dashboard access is limited to authorised customer admins within the product.

If detailed audit logging requirements are part of your evaluation, current capabilities and roadmap can be reviewed during the security and onboarding process.

Security posture

How is data encrypted in transit and at rest?

Data is protected using standard encryption controls:

• in transit
• at rest

What authentication methods are supported, and how are tokens rotated or revoked?

Authentication and token-handling details depend on the deployment model and integration path.

These controls and operational details can be reviewed with customer security and platform teams during implementation planning.

Deployment

What deployment methods are supported?

Supported deployment methods include:

• VS Code extension (self-serve)
• Local Agent via MDM for enterprise rollout

What happens if a developer disables the agent or extension?

Data collection stops, and activity will no longer appear in reporting.

Policy and governance

What does AI usage policy mean in Trust Agent: AI today?

Policy is currently a visibility and governance layer for approved vs unapproved usage.

It is not an enforcement control.

Can policy be scoped by team or repo?

Initial policy is positioned at company level.

More granular scoping is future-looking.

Outcomes and ROI

What outcomes does Trust Agent: AI aim to improve?

Trust Agent: AI aims to support:

• improved AI governance visibility
• stronger compliance confidence
• more targeted interventions
• reduced repeat risk over time

How do you show impact or improvement?

Impact can be shown through measurable trends such as:

• reduced use of unapproved tools
• increased policy adherence
• improved learning completion
• fewer repeated risk patterns

MCP

What is MCP in simple terms, and why does it matter for enterprise risk and governance?

MCP is a way for AI tools or assistants to connect to other tools, systems, or services.

It matters because it creates a new tooling supply chain inside developer workflows, and enterprises need visibility into what MCP infrastructure exists before they can govern it safely.

What MCP signals can you detect?

MCP visibility is based on:

• observed activity
• available instrumentation

It should be positioned as inventory and observed usage, not full coverage.

How do we distinguish MCP installed on device vs MCP used?

Conceptually:

• Installed means MCP-capable tooling exists on the device
• Used means we have observed MCP activity

Can we connect MCP usage to users and developers?

Not today, but this is coming very soon.

Compatibility

VS Code extension compatibility matrix

Legend 

• Verified / Supported – Verified as complete (MCP + Code Snippet Detection) or supported, depending on context
• In progress – Testing and verification required
• Blocked / Not supported
• Not applicable / Not currently verified

Supported tools and providers