Connected is the registry of every AI agent that has successfully authenticated with the Agen.co gateway — the component that sits between your AI agents and the tools/connectors they call, checking every request against your policies before it goes through. If an agent is calling tools through Agen.co, it shows up here.
For a CISO, this page answers three questions: which agents are talking to our systems right now, how trustworthy is each one, and whose identity is behind each agent's actions.
Where to find it
Where to find it
In the Agen.co portal left sidebar, under Agents, click Connected.
An agent reaches Connected status one of two ways:
- Automatic handshake. An MCP client (an AI tool such as Claude, or an internal application) is pointed at your gateway URL. The moment it establishes a connection, Agen.co records the handshake and the agent appears in the list automatically — no manual setup needed. If you haven't connected anything yet, the page shows a single line: gateway online, awaiting first handshake. Open the connection guide from that page for step-by-step configuration instructions covering six common client environments; the process is the same in all of them — copy the gateway URL, paste it into the client's MCP configuration, restart the client.
- Manual registration. Click + New Agent and fill in a short form yourself. Use this when you want an agent's identity, ownership, and trust posture defined up front — before it ever makes a call — rather than waiting for it to show up on its own.
Every agent registered in Agen.co is one of two types. This choice determines whose permissions apply when the agent makes a tool call — it's the single most important security distinction on this page.
| Connected | Autonomous | |
|---|---|---|
| How it authenticates | On behalf of a specific human user, via OAuth redirect (the user is sent to a login screen, signs in, and grants access — the same flow you'd use to "Sign in with Google") | Independently, using its own credentials — no human signs in |
| Whose access applies to its tool calls | The signed-in user's permissions and access context. If a Connected agent calls a tool, it can only do what that specific user is allowed to do. | The agent's own credentials, scoped by the policies and connectors you assign to it directly |
| Typical use case | An assistant acting for a person — e.g. a chat agent that reads a user's calendar or drafts email as that user | An unattended process — a backend pipeline, a scheduled job, or any agent that runs outside a user session, with nobody logged in |
| Traceability | You can always answer "which person is behind this agent's request?" via the Connected Users tab (see below) | There is no per-user identity to trace — accountability lives at the agent/credential level instead |
Why this matters for security review
Why this matters for security review
Because a Connected agent inherits the acting user's permissions, a Connected agent is never more powerful than its least-restricted user. An Autonomous agent, by contrast, has no user to fall back on — its own credentials and the policies you attach to it are the entire boundary of what it can do. When reviewing a new agent registration, always confirm the type matches how the agent actually operates: registering a backend job as Connected (or vice versa) misrepresents what's really authorizing its access.
Click + New Agent to open the registration panel. Start by choosing the Agent type — Connected or Autonomous — since the type determines which fields appear next.
For a Connected agent, fill in:
| Field | Required | Description |
|---|---|---|
| Agent Name | Yes | A descriptive name so you can recognize the agent later (e.g. "Sales Assistant") |
| Agent Class | No | A tag for grouping agents by category, e.g. Internal vs. external/third-party |
| Owner Email | No | The person accountable for this agent — who to contact if it needs review |
| Redirect URLs | No | The OAuth callback URL(s) the agent is allowed to use when completing the sign-in flow. Click + Add URL to add more than one. |
For an Autonomous agent, the form is shorter — there's no user sign-in flow, so Agent Class and Redirect URLs don't apply:
| Field | Required | Description |
|---|---|---|
| Agent Name | Yes | A descriptive name for the agent |
| Description | No | What the agent does — useful context since there's no user session to infer it from |
| Owner Email | No | The person accountable for this agent |
Click Register Agent to save. The agent immediately appears in the Connected list with status Provisioned, ready to start authenticating.
Each row in the list summarizes one agent at a glance:
| Column | What it tells you |
|---|---|
| Name | The agent's name and its unique ID |
| Status | Its current connection state, e.g. Active, Provisioned (registered but hasn't connected yet) |
| Tier | The agent's trust tier (Bronze, Silver, Gold — driven by its Trust Score; see below) |
| Platform | How the agent got here — registered for a manually created agent, auto detected for one that arrived through an automatic handshake |
| Owner | The Owner Email set at registration, if any |
| Class | The Agent Class set at registration, if any |
| Last Active | When the agent last made a tool call — or Never, if it hasn't yet |
| Trust Score | Its current cumulative trust score (see below) |
Click any agent's name to open its detail view.
An agent's detail view has three tabs: Overview, Activity, and Connected Users.
Trust Score is a cumulative security signal: it starts at a base value and increases as you enable individual verification signals for that agent. Each signal you turn on is reflected in the score immediately, and the score determines the agent's tier (Bronze / Silver / Gold).
The Signal Breakdown table lists each verification signal, its point value, and whether it's currently enabled:
| Signal | Points | What it verifies (plain terms) |
|---|---|---|
| DPoP | +30 | Demonstrating Proof-of-Possession — cryptographic proof that whoever is making the call actually holds the private key tied to the agent's credentials, not just a copied token |
| mTLS | +25 | Mutual TLS — both the agent and the gateway present certificates to each other during the connection, so the agent's identity is verified at the network layer, not just at the application layer |
| IP verification | +20 | The request is checked against an expected set of IP addresses or ranges, catching calls from unexpected locations |
| User identity | +15 | For Connected agents, confirms a real, currently-valid user identity is behind the call |
| Behavioral | +10 | The agent's call patterns are checked against its historical baseline, to flag unusual or anomalous behavior |
| CIMD Client | +20 | Client identity metadata is validated against a trusted registry, confirming the calling application is what it claims to be |
The higher an agent's Trust Score, the more verification is actually happening behind its requests — which is exactly the input you'll use later to write differentiated policy rules (see Trust Score in Policies below).
The Credentials panel on the right shows when the agent's credentials were issued, its Client ID, a masked Secret (click the eye icon to reveal it), and its Allowed Connectors — the list of connectors this agent is currently permitted to reach.
The Activity tab shows the tools this agent has called most frequently, over the last 30 days: total call volume, how many distinct tools it has used, its single most-called tool, and its average calls per day. The Top Tools chart breaks this down further, so you can see at a glance which specific operations are running and at what volume — useful for spotting an agent that has started calling something it never used to.
For a Connected-type agent, this tab lists every user who has authenticated through it, and when each was last active. This is how you trace which real identities are behind an agent's requests — the answer to "if this agent misbehaves, whose access made that possible?" (Autonomous agents don't have this tab populated in the same way, since they don't authenticate on behalf of individual users.)
An agent's identity doesn't stay confined to the Connected page — it feeds directly into the targeting rules you configure in Policies and Data protection. When building a targeting rule, you can select any of the following agent attributes as a condition: Agent Name, Agent Tier, Agent Source, Agent Status, Agent Class, or Agent Trust Score.
In practice, this means the same tool call can be handled completely differently depending on which agent is making it — governed by one rule set, differentiated by agent identity. For example, you could write a rule so that a high-trust, internally-owned agent (Gold tier, Agent Class = Internal) gets straight-through access to a sensitive tool, while an unverified or externally-sourced agent hitting the exact same tool gets denied, masked, or routed to an approval flow instead. The Trust Score and Signal Breakdown data from the Overview tab is what makes this kind of tiered, risk-based rule possible.
- Policies — build targeting rules that key off agent identity and trust
- Data protection — apply masking rules differentiated by agent
- Connectors — see which connectors are available for agents to call