Building Trent's agent-native product surface

By Himamsu Siriseni @ Trent (Agentic AI Security)

As AI helps attackers move faster, the time between a security finding and a verified fix matters even more. When a scan flags a problem, someone still has to understand it, make the change, and check the result. You should be able to hand the AI agent a finding, and return to a fix you can review, with an explanation of what it checked.

For example, Trent scans a repository and the supporting project context, then produces a threat model, and a remediation plan with proposed fixes. Then your coding agent implements the fixes, and Trent rescans the committed changes to check the result. You can work with the analysis through Trent's dashboard or through your agent, using the Model Context Protocol (MCP), because both connect to the same backend. The connection, tools, and guidance that make this possible are what we mean by Trent's agent-native product surface.

Building that workflow taught us a broader lesson about when to ask and when to act. Running a local server, copying keys, and answering unnecessary approvals all add work for the customer before a fix is ready.

A real, redacted Trent finding alongside its proposed fix.

Connecting to Trent

Previously, connecting your agent to Trent meant installing a pip package that ran a local MCP server on your machine. You had to keep that process running and upgrade the package to get new tools and fixes.

Now we provide a remote MCP server hosted by Trent, replacing the local package with a plugin that installs the connection and three skills. Customers get updated tools through this connection without running, maintaining, or upgrading a server locally.

Authentication

The local server supported API keys and its own browser sign-in flow. With a key, you had to create it, paste it into configuration, and keep it current and secure. With Trent's remote MCP server, your MCP-compatible coding client opens a browser so you can sign in to Trent. API keys remain available for headless use.

Dynamic Client Registration (DCR) creates client registrations that the authorization server must maintain. Client ID Metadata Documents (CIMD) let a client identify itself with a stable HTTPS metadata URL. The MCP specification has deprecated DCR in favor of CIMD, and Trent's CIMD sign-in is live for Claude Code, Codex, VS Code, and Copilot.

Supporting DCR would have let more clients use browser sign-in. We decided to focus on CIMD to encourage clients to adopt the protocol's recommended registration method and to spend our time on customer requests instead of maintaining a second, deprecated path.

Reviewing and Correcting Findings

You can ask Trent to assess findings from another scanner in the context of your project. Your agent includes those findings in trigger_analysis, and Trent runs a full project scan. We merged scan_with_findings into that tool so the agent can add evidence without choosing a different tool for the same task. This is an example of designing tools around the workflow, a principle we covered in our earlier post on MCP reliability.

Implementing and Verifying the Fix

While your coding agent works on the fix, security_advisor provides quick advisory feedback on uncommitted changes. We removed scan_local_diff because it mixed those reviews into the project's scan history. Once the code is committed, your agent requests a repository scan and checks the completed results to verify the fix.

The same finding shown above, after implementation and rescan, with the verified fix visible in Trent.

When to Ask & When to Act

When you ask an agent to prepare a fix for review, reading the relevant code, writing the patch, and running available checks are part of the job. Asking, "Should I make the change?" after investigating makes you repeat a decision you already made. Within the access you've granted, the agent should return the patch, the checks it ran, and any remaining uncertainty. We're removing the pause for plan approval in Trent's remediation flow so your next review can focus on the implemented fix and its checks.

The agent should ask when it needs information it can't find, reaches a choice you haven't made, or needs access you haven't granted.

Our earlier hook asked a model after every coding-agent turn whether to call Trent. Repeating that decision spent tokens and interrupted our developers, so we retired the hook. Today, a developer invokes a skill, or the agent automatically reaches for the security advisor tool, when the task calls for it.

In Trent, access changes and irreversible actions stay in the dashboard. Deleting projects, managing keys, creating organizations, inviting members, and installing GitHub apps can erase work or change who has authority. Those decisions stay with the human who accepts their consequences.

Apply this Principle to Your Agent

Users should be able to ask for an outcome. The agent should work out and complete the steps within the scope and permissions they've given it. Design its requests for input as carefully as its tools. Each request should identify a missing fact, an unresolved choice, or additional permission the agent needs.

Review a real run and stop at each request for input or approval. Ask yourself, "What do we need from the user here?" Have the agent look for answers in the available context before asking. Have it pause when only the user can supply the answer or grant the access, and explain what depends on it.

Building an Agent-Native Product

This means designing the whole path from setup to a result the customer can review. Whether you're building or using an agent-native product, call out the friction you encounter and ask whether the product could handle that work, while preserving the decisions that need your judgment.