Agent Identity in Safeguard: Which AI Agent Holds What Access

Safeguard's agent identity (GA) answers three questions for every AI agent in your estate: which agent is it, what can it reach, and at what level. Safeguard answers them in three places. For assistants that work inside Safeguard, the answer comes from the signed-in person, their role and the tools your tenant has switched on. For coding agents on your people's computers, AI agent discovery reports each agent's permissions, MCP servers, skills, models and sessions. For agents calling your own MCP servers, MCP Guardrail keeps a record per agent with a status, scores and a per request audit trail.

That is the short answer. The rest of this post explains why "which agent holds what access" has become an audit question rather than a curiosity, what the standards say about it, and how to build the answer in Safeguard step by step from the product docs. It closes with the limits, because an inventory that overstates what it covers is worse than no inventory.

Key takeaways

• Agent identity: GA. Safeguard tracks which agent holds what access, at what level.
• Safeguard MCP server: GA. An assistant connected through OAuth acts as the signed-in person, inside that person's tenant, organization and product scope.
• MCP tool gating: GA. Each tool has its own switch per tenant. Tools an assistant cannot see, it cannot call, and the server falls back to a small read-only set if it cannot resolve the list.
• AI agent discovery: GA. The Safeguard CLI and Desktop app report the coding agents on each computer, what each may do, and what it did, under Assets › Inventory › Asset discovery.
• MCP Guardrail (the docs call it Guard): GA. Registered agents carry a status of active, blocked or quarantined, running risk and anomaly scores, and an audit event for every request.
• Roles, SSO and keys: GA. Built in roles, custom roles, SAML 2.0, OpenID Connect, SCIM 2.0 and separate key families decide the level a person, and therefore their assistant, works at.
• Approvals for risky agent steps: GA. Covered in depth in our post on human approval for agent actions; this post links to it rather than repeating it.

Why "which agent holds what access" is now an audit question

Engineering teams now run coding agents on laptops, assistants in chat tools connected to internal systems, scheduled agents that run unattended, and customer facing agents that call internal tools through MCP. Each has its own settings, auto approved tools, MCP servers and credentials.

The access often looks like this:

• A coding agent allowed to run shell commands without asking, with an extra folder outside the project added months ago.
• An assistant connected to a security platform under one engineer's account, with whatever that engineer's role allows.
• An MCP server exposing a database tool, called by three agents, one of which nobody remembers deploying.
• A long lived API key referenced in an agent's environment, issued to a person who has since changed teams.

When something goes wrong, the questions an incident lead or auditor asks are always the same. Who did this? Was it a person or an agent? Which agent, running for whom? What was it allowed to do, and who allowed it? If those answers live in a dozen settings files on a dozen laptops, the honest answer is "we do not know".

Safeguard's own offering material puts it plainly: as enterprises point agents at their own infrastructure, "who did this, and was it a human or an agent" becomes an audit requirement. Agent identity is the part of Safeguard that answers it.

What the standards say about agent access

No single standard is titled "agent identity". The requirement comes from several directions at once, and an auditor will usually reach for whichever one your organization already follows.

OWASP Non-Human Identities Top 10 (2025)

The OWASP Non-Human Identities Top 10 lists the most pressing risks that machine and service identities create. Several of its 2025 entries describe exactly the agent access problems above:

• NHI1:2025 Improper Offboarding. Identities that stay active after the person, project or service they belonged to is gone.
• NHI5:2025 Overprivileged NHI. Identities that hold more access than their job needs.
• NHI7:2025 Long-Lived Secrets. Credentials that do not expire, so a leak stays useful.
• NHI9:2025 NHI Reuse. One identity shared across several workloads, so you cannot tell them apart.
• NHI10:2025 Human Use of NHI. People using machine credentials, which blurs who did what.

Each of these is a question about which identity holds what access. An AI agent is a non-human identity with an unusual property: what it does next is decided by a model reading text, so the gap between what it is allowed to do and what it actually does can be wide. We map the full list to agents in which OWASP non-human identity risks apply to AI agents.

OWASP Top 10 for LLM Applications 2025: LLM06 Excessive Agency

OWASP's LLM06:2025 Excessive Agency describes damage done when an LLM based system acts on unexpected, ambiguous or manipulated output. It names three root causes: excessive functionality, excessive permissions and excessive autonomy. Its mitigations start with scope, not with approval prompts:

1. Minimize extensions: offer the agent only the tools it needs.
2. Minimize extension functionality: a tool that reads email should not also send it.
3. Minimize extension permissions: the tool's own access to downstream systems should be as narrow as possible.
4. Complete mediation (item 7 in OWASP's list): enforce authorization in the downstream system rather than trusting the model to decide what is allowed.

You cannot minimize what you have not listed. Agent identity is the list.

The Model Context Protocol specification

The MCP authorization specification (version 2025-06-18) requires MCP clients to implement Resource Indicators for OAuth 2.0 as defined in RFC 8707, and requires MCP servers to validate that access tokens were issued specifically for them as the intended audience. The companion security best practices page describes two failure modes that matter for identity: the confused deputy problem, where a proxy server acts with authority the caller should not have, and token passthrough, where a server forwards a token it received instead of using its own. Both are identity bugs. An agent that can borrow someone else's token has no meaningful identity of its own.

NIST guidance on least privilege and zero trust

NIST SP 800-53 Rev. 5, the control catalogue most US federal and many private programs use, groups account management and least privilege in its access control family. NIST SP 800-207, Zero Trust Architecture, describes moving defenses from network perimeters to users, assets and resources, and assumes no implicit trust based only on network location or asset ownership. Neither document was written with AI agents in mind, but both apply directly: an agent is an account, and its access should be granted per resource and reviewed.

The NIST AI Risk Management Framework (AI RMF 1.0) adds the governance side through its Govern function: in practice, knowing which AI systems you run and who answers for them.

EU AI Act: record keeping and human oversight

For high risk AI systems, Article 12 of the EU AI Act requires that the system technically allow the automatic recording of events (logs) over its lifetime, for traceability. Article 14 requires that such systems be designed so people can oversee them effectively. Most internal coding agents are not high risk systems under the Act, but buyers increasingly ask for the same evidence anyway: a log of what each agent did and a way for a person to stop it. The detail of Article 14 and approvals is in our human approval post.

Requirement versus what Safeguard does versus what you still own

How Safeguard answers "which agent holds what access"

Safeguard looks at agent access from three positions. Each one sees a different slice, and together they cover the common cases.

Position 1: agents working inside Safeguard

Safeguard is built to be operated by AI agents as well as people. Its remote MCP server at mcp.safeguard.sh lets assistants such as Claude and ChatGPT read and act on your Safeguard data. The docs are specific about identity here:

• With an existing account, sign in runs through OAuth against your Safeguard workspace, and the agent acts as the signed in user, inside their tenant.
• Tenant, organization and product scope travel with each session. An agent never sees another tenant's data, and it can switch organization or product mid session only where the person belongs to several.
• Every tool call runs under the session's scope with the platform's standard audit logging.

So for an assistant inside Safeguard, the level of access is the overlap of two things: what the signed in person's role allows, and which tools the tenant has switched on.

The second half is MCP tool gating. Each tool has its own feature flag. When an assistant connects, the server works out the tools enabled for the tenant and uses that set for both discovery and execution, so an assistant can never call a tool it cannot see, or see a tool it cannot call. A new workspace starts with a small set of read only tools: listing products and projects, reading a project, listing and reading vulnerabilities, and listing findings. Everything else, including adding integrations, starting scans, billing and admin changes, ships switched off and is turned on per tenant by an administrator. If resolution fails during an outage, the server falls back to the small default set. The docs call this "fail safe, never fail open".

Position 2: agents on your people's computers

Most agent access in a software company today lives on laptops. AI agent discovery runs inside the Safeguard CLI and the Safeguard Desktop app and reports, per device and per person:

• The agents installed and running, their versions, and what each is allowed to do: shell commands, file edits, network access, auto approved tools, sandbox and permission mode, and extra folders it can reach.
• The MCP servers each agent is connected to, with transport, package and the tools seen in use. Environment and header values are never read, only their names.
• Skills, plugins, extensions, rules, commands and sub agent definitions installed into each agent, each with a hash of its definition.
• Local model files and the models each agent was configured with or used.
• Credentials an agent refers to, by name and kind only, for example an environment variable name or "login file present". Credential values are never read or sent.
• Activity from the agents' own local session files, drawn as a chain from the prompt to the agent, its tool calls, the sub agents it started and their calls.

The docs list the supported agents, including Claude Code, OpenAI Codex CLI, Cursor, GitHub Copilot, Gemini CLI and several others, and say which of them have readable session activity today. Agents not on the list are not detected.

This is the position that answers "at what level" most directly. A coding agent set to auto approve shell commands, with network access and an extra home folder grant, holds a very different level of access from the same agent set to ask first inside one project folder. The access summary shows that difference per agent, per device.

Position 3: agents calling your own MCP servers

When you build or run MCP servers yourself, or put third party servers in front of your agents, the question flips: which agents are calling this server, and what are they allowed to call? MCP Guardrail (the docs call it Guard) answers it with two kinds of record.

Servers. Each MCP server you register has a name, an upstream URL, a transport, an auth type and a status. Once a server is registered and active, Guard discovers the tools it exposes on a schedule and keeps a health status.

Agents. Each agent you register has a name, a description and free form metadata such as team and environment. From then on Guard maintains:

Policy rules can target a specific server or agent instead of applying to every request in the organization, and each rule resolves to allow, deny or monitor. Our MCP Guardrail post covers policies and the proxy in depth. For identity, the important parts are the agent record, the lifecycle actions and the audit trail.

Underneath all three: people, roles and keys

Every agent eventually traces back to a person or a key, so the identity layer for people matters as much as the agent records.

Safeguard's docs describe a hierarchy of organization, team, project and asset, with roles scoped to a team or the whole organization. The built in roles are:

Custom roles are composed from a permissions matrix and can carry restrictions, for example limiting a role to production environments. Sign in supports SAML 2.0, OpenID Connect, SCIM 2.0 provisioning and deprovisioning, and just in time provisioning, and enterprise tenants can require SSO for every login and re-authentication for sensitive actions.

Keys come in separate families, and the difference matters for agents:

• User API keys are bound to a user and inherit that user's role. They are revoked if the user is deprovisioned.
• Service tokens are bound to a service identity, used for CI and automation, and scoped to specific permissions.
• Workload identities are OIDC federated tokens from CI systems and cloud providers, with no long lived secret.
• Organization secret keys belong to the organization rather than a person. They are what the Guard SDK uses to pull your live policy into an agent or MCP server process. Revoking one takes effect at once.
• MCP keys, created under Settings › Developer, exist for MCP clients that can only send a fixed header and cannot run OAuth.

The point for agent identity: when an assistant runs on a user API key or an OAuth session, its level is that person's level. When it runs on a service token, its level is whatever you scoped that token to. Choosing the credential is choosing the identity.

Step by step: build the agent access picture in Safeguard

The steps below follow the docs. Where the docs do not show a screen or command, the step describes the outcome instead of inventing one.

Step 1: write down the questions you need to answer

Start with the audit questions, not the tool. A short list works:

1. Which AI agents run on our people's computers, and which of them can run commands without asking?
2. Which assistants are connected to Safeguard, and as whom?
3. Which agents call our own MCP servers, and which tools do they call?
4. For each, who is the owner, and when did we last review it?

Each question maps to one of the three positions above. Keep the list; you will use it for the review in step 10.

Step 2: connect assistants to Safeguard through the connector directory

For Claude, the docs give the connector directory as the shortest route, with no URL to paste:

1. Open Safeguard's entry in Claude's connector directory (you need to be signed in to claude.ai).
2. Select Safeguard and connect.
3. Sign in to Safeguard, check the app name and the host the authorization code will be sent to, then click Authorize access.

On a Claude Team or Enterprise plan, an Owner or Primary Owner adds the connector for the organization first, and members then connect it for themselves. ChatGPT follows the same OAuth pattern. Our post on Safeguard in the Claude and ChatGPT connector directories walks through both.

The identity outcome: each person who connects signs in as themselves. The assistant then works at that person's level inside their tenant, and its tool calls land in the platform's audit logging under that session. The docs add that Safeguard accepts only OAuth client IDs it issued itself.

Avoid sharing one Safeguard account across a team "for the assistant". That is NHI9 reuse and NHI10 human use of a machine credential at once, and it destroys the answer to "who did this".

Step 3: verify which tools the assistant can actually use

Ask the assistant: "What Safeguard tools do you have?" A working connection lists tools such as listing projects and vulnerabilities. A new workspace shows only the small read only default set.

If the assistant tries a tool your tenant has not switched on, the call does not break the connection. It returns a normal tool result flagged as an error. The docs show the shape:

{
  "content": [
    {
      "type": "text",
      "text": "Tool \"safeguard_scan_manifest\" is not enabled for this tenant. An administrator can enable it via MCP tool feature flags."
    }
  ],
  "isError": true
}

That message is the gating check on execution doing its job. Treat it as an access decision to review, not a bug to work around. If the tool should be on, the person who administers your tenant enables it under Feature Flags, where per tool flags are grouped in the mcp category. If you do not see that screen, it is because Feature Flags is administered on your tenant's behalf; ask your Safeguard administrator.

When testing, note that many MCP clients cache the tool list at session start, so a newly enabled tool may need a fresh session.

Step 4: set the level through roles, not through the assistant

Because an OAuth connected assistant acts as the signed in person, its ceiling is that person's role. Review roles before you widen tools:

• People who only need to ask questions of the data can hold Viewer or Auditor.
• People whose assistants will triage and remediate need Security Engineer or Developer on the right teams.
• Few people need Security Lead, and fewer need Admin or Owner. An assistant on an Owner's session can do whatever the tenant's enabled tools allow, including admin changes if those tools are on.

If you need a narrower level than any built in role, compose a custom role from the permissions matrix. The docs show the shape:

apiVersion: safeguard.sh/v1
kind: Role
metadata:
  name: production-responder
spec:
  permissions:
    - findings:read
    - findings:triage
    - policies:evaluate
    - workflows:run
  restrictions:
    environments: ["production"]
    severity_max: "critical"

This is the practical meaning of "at what level": the tool list decides what kinds of action exist, and the role decides which of them this person, and their assistant, may take.

Step 5: give automation its own identity

For an agent that runs unattended, such as a scheduled job or a pipeline step, do not reuse a person's session. The docs describe service tokens bound to a service identity and scoped to specific permissions, and workload identities federated over OIDC from CI systems and clouds so no long lived secret is stored. Name the identity after the agent and record its owner. Our guide on whose identity a scheduled AI task acts under covers the design choice in general terms.

For an MCP client that cannot run OAuth, create an MCP key under Settings › Developer and send it in the Authorization header. If you do not see the Developer tab, the docs note it appears under the ESSCM product context; check that you opened Settings from there, or ask your Safeguard administrator.

Step 6: switch on AI agent discovery

AI agent discovery has three switches, in this order:

1. Safeguard enables it for your organization. Ask your Safeguard contact.
2. An administrator turns it on and sets the policy. The policy covers how file paths are shown (shortened by default, or hashed, or full), whether command lines and web search queries are collected, extra model folders, how often devices report, retention, enrollment (ask each person, or enroll everyone with a notice) and whether people may opt out.
3. Each person allows it on their computer after reading exactly what is collected. In Safeguard Desktop: Settings › Privacy › AI agent discovery › Allow AI agent discovery. In the CLI:

safeguard aidr collect status     # your organisation's setting, your choice, the last delivery
safeguard aidr collect on         # read the notice and allow it
safeguard aidr collect show       # print exactly what the next run would send (nothing is sent)

The docs also show a dry run that collects locally and sends nothing, a one time send, and an off switch that stops collection and deletes what that computer sent:

safeguard aidr collect --dry-run  # collect locally and summarise, send nothing
safeguard aidr collect            # collect and send once now
safeguard aidr collect off        # stop, and delete what was sent from this computer

Run the show command on your own machine before rolling out. It is the fastest way to answer an employee's "what exactly are you collecting?" with the real payload rather than a policy document.

From then on, collection runs in the background while the Safeguard runner or Desktop app is running, on the interval your organization sets (the docs give 15 minutes as the default).

Step 7: read each agent's access summary

Open Assets › Inventory › Asset discovery in the Safeguard app. The page has filters for device, person and agent, and five tabs:

Opening an agent shows its access summary, the projects it worked in, its credentials by name and its sessions. Opening a session draws the chain as a diagram (prompt, agent, tools, sub agents, their calls) and as a plain timeline.

Work through the Agents tab with three filters in mind:

• Auto approval. Which agents run shell commands or file edits without asking? These are your highest level agents, regardless of who owns them.
• Reach. Which agents have network access, extra folders outside the project, or MCP servers that connect to production systems?
• Credentials by name. Which agents refer to provider keys or cloud credentials, and are those the person's own or shared?

Each report says, per agent, whether its sessions were read, not supported, or had no local files. A gap is never shown as "nothing happened", which matters when you present the inventory to an auditor.

Step 8: register the agents that call your MCP servers

For MCP servers you operate, register each server and each agent with MCP Guardrail. The docs are explicit that both are registered on purpose: Guard does not scan your network and create server or agent records by itself, and an agent must have a record before Guard can attach activity, risk scoring or lifecycle actions to it.

Give each agent a name that says what it is and where it runs, a description, and metadata for owner team and environment. A newly registered agent always starts as active. The docs show a registered agent coming back like this:

{
  "name": "checkout-assistant",
  "description": "Customer-facing checkout agent",
  "status": "active",
  "risk_score": 0,
  "anomaly_score": 0,
  "total_requests": 0,
  "blocked_requests": 0,
  "last_seen_at": null,
  "metadata": { "team": "commerce", "env": "prod" }
}

Our post on naming and tagging AI agent identities has a naming scheme that works well here.

Step 9: read what each agent did, and stop one if you need to

Every request Guard evaluates, whether allowed, denied or monitored, is written to an append only audit trail. Each event carries the agent and server it relates to, the method and tool, the decision, the rule that matched and why, risk, jailbreak and anomaly scores, PII types detected and fields redacted, latency and outcome. The docs show a denied request:

{
  "agent_id": "9c1e4a2b-...",
  "server_id": "7d2f5b3c-...",
  "method": "tools/call",
  "tool_name": "run_sql_query",
  "action": "deny",
  "rule_name": "Block raw SQL from untrusted agents",
  "deny_reason": "input matched block_pattern rule",
  "risk_score": 0.83,
  "anomaly_score": 0.91,
  "status_code": 403,
  "created_at": "2026-07-07T14:02:31Z"
}

That single record answers "which agent, calling which server, tried which tool, and what happened". Note that monitor is a separate outcome from deny: a monitored request went through but was flagged for review.

When an agent misbehaves, you have two levers. Lifecycle actions change the agent's own status at once: block, unblock or quarantine. Policy rules are for standing decisions that apply every time. Use the first for an incident and the second for the rule you write afterwards.

Step 10: review on a cadence and offboard cleanly

Agent access drifts. A monthly or quarterly review, sized to how fast your agents change, keeps it honest. For each review:

1. Export or screenshot the Agents tab for the period, filtered to agents with auto approved shell or file access.
2. Compare the tenant's enabled MCP tools with what teams actually asked for.
3. List registered MCP Guardrail agents with status, last seen and blocked request counts. Retire records for agents nobody owns.
4. Check that people who left or moved teams were deprovisioned. User API keys bound to a deprovisioned user are revoked with them.
5. Revoke organization secret keys that no longer back a running agent. Revocation is immediate, so plan it rather than doing it mid incident unless that is the point.

For workspace activity such as role changes, policy changes and integration changes, the Portal audit log lives under Settings › Audit Logs, with filters for date range, actor, action type and resource, and export as CSV, JSON or a PDF report. It is a different log from the MCP Guardrail request trail, and the docs say so: one records administrative activity, the other records individual MCP request decisions.

Our guides on how often to review AI agent access and how to offboard an AI agent identity go deeper on cadence and offboarding.

Which question goes where: a decision table

A worked example: one agent, three views

Here is how the three positions combine for one plausible agent, described in general terms rather than from a real customer.

A platform engineer uses a coding agent on their laptop. The same engineer has connected an assistant to Safeguard through the connector directory, and the team runs an internal MCP server that exposes a database query tool.

• Asset discovery shows the coding agent on the engineer's laptop with shell commands auto approved, network access on, an extra folder outside the project, two MCP servers configured (one of them the internal database server), and a provider API key referenced by name. Its sessions show a run last week that called the database server's query tool.
• Safeguard's MCP server shows the assistant acting as the engineer, inside their tenant, with the tenant's enabled tool set. The engineer holds Security Lead, so the assistant can manage policies if those tools are on.
• MCP Guardrail shows the agent's record on the internal server, its blocked request count, and a denied raw SQL call with the rule that matched.

Put together, the answer to "which agent holds what access, at what level" is concrete: this coding agent can run commands without asking and reach the database server; this assistant acts with Security Lead rights; and this is the request the guardrail stopped. The fixes are equally concrete: switch the coding agent to ask first, drop the extra folder, give the engineer's assistant a narrower role for daily use, and keep the deny rule.

What Safeguard does not do

Be clear about these limits before you present the inventory as complete.

• It does not find agents on its own everywhere. AI agent discovery runs only on computers with the Safeguard CLI or Desktop app, only for the supported agents the docs list, and only after the organization turns it on and each person allows it (or is enrolled with notice, if your policy says so). Agents running on servers, in cloud functions or inside SaaS tools are outside its view.
• MCP Guardrail does not auto register servers or agents. You register each one. Guard discovers the tools a registered server exposes, on a schedule, but it does not create server or agent records from network traffic.
• MCP tool gating is per tenant, not per person or per agent. Everyone connecting under the same tenant, organization and product sees the same enabled tool set. For finer control over your own MCP servers, use MCP Guardrail policies; for Safeguard's own tools, the person's role is the other half of the limit.
• Activity is not available for every agent. The docs mark session activity as not supported yet for several of the listed agents, and never read for one whose history files hold the conversation itself. The report says which, so do not read silence as inactivity.
• Some audit conveniences are not there yet. The docs say the MCP Guardrail audit query cannot filter by agent or server today, so you filter the returned events yourself, and the alert rule schema is documented but not yet evaluated against live traffic, so alerts on an agent's behaviour are not something to rely on today.
• Safeguard does not replace your identity provider or your privileged access tooling. It signs people in through your SAML or OIDC provider and provisions over SCIM. Who is a member, and how strong their login is, is decided there.
• It does not read credential values, prompts or tool output by default. That is a privacy choice, and it means agent discovery tells you an agent refers to a key by name, not whether the key is valid, over privileged at the provider or leaked.
• It does not make you compliant with any regulation. Logs, inventories and approvals are evidence. Whether they meet EU AI Act Article 12 or 14 for a given system is a legal judgement your organization makes.

Common mistakes

• Treating the assistant as its own identity inside Safeguard. Through OAuth it acts as the signed in person. If that person is an Owner, the assistant's ceiling is Owner. Fix the role, not the prompt.
• Turning on every MCP tool to stop the "not enabled" errors. Each error is an access decision. Enable tools per need, starting from the read only default, and keep write capable tools such as merging pull requests for the teams that need them.
• Sharing one account or one key across a team's agents. You lose the answer to "who did this", which is the whole point of the exercise. Give each automation its own service identity.
• Rolling out agent discovery without showing people the payload. Run safeguard aidr collect show yourself, share what it prints, and use the enrollment and opt out settings your works council or privacy team expects.
• Reading "no sessions" as "no activity". Check the per agent status for "not supported" before drawing conclusions.
• Registering agents with vague names. "agent-1" in an audit trail is useless at 2 a.m. Name agents for what they do, where they run and who owns them.
• Forgetting the keys that are not people. Organization secret keys and service tokens outlive projects. Put them on the review list.

FAQ

What is agent identity in Safeguard?

Agent identity (GA) is Safeguard's way of tracking which AI agent holds what access, at what level. In practice it combines the identity of assistants working inside Safeguard, the agent inventory from AI agent discovery on your people's computers, and the per agent records MCP Guardrail keeps for agents calling your own MCP servers.

When Claude or ChatGPT is connected to Safeguard, whose permissions does it use?

The signed in person's. The docs say that with OAuth the agent acts as the signed in user, inside their tenant, with tenant, organization and product scope carried per session. The tools it can call are further limited to those your tenant has switched on.

Can I give one AI assistant fewer Safeguard tools than another?

Not through MCP tool gating, which resolves per tenant rather than per person. You can narrow what a person's assistant may do through that person's role, and for MCP servers you run yourself, MCP Guardrail policies can target a specific agent.

How do I see which AI coding agents my developers run?

Turn on AI agent discovery, then open Assets › Inventory › Asset discovery › Agents. Each agent on each device appears with its access summary, models, skills and MCP servers. It needs the organization switch, an administrator policy, and each person's consent or notice enrollment.

Does Safeguard read our API keys or prompts when it inventories agents?

No for keys: credential files are only checked for presence, and credential values are never read or sent. Prompts, responses and full tool inputs are not collected unless Safeguard enables prompt capture for your organization, an administrator turns it on and the person separately agrees, and even then the text is masked and shortened.

How do I stop a misbehaving agent that calls our MCP server?

If the agent is registered with MCP Guardrail, block or quarantine it. That changes the agent's own status at once. Then write a policy rule for the behaviour so the decision is recorded as a standing rule rather than a one off.

What happens to a person's keys when they leave?

The docs say user API keys are bound to a user, inherit that user's role and are revoked if the user is deprovisioned. Organization secret keys belong to the organization, not a person, so review and revoke them separately.

Is there an audit trail of what each agent did?

Yes, in more than one place. Safeguard's MCP server applies the platform's standard audit logging to every tool call. MCP Guardrail writes an append only event for every request it evaluates, with the agent, server, tool and decision. AI agent discovery keeps session timelines per agent. Workspace changes such as roles and policies are in Settings › Audit Logs.

Does agent identity help with the OWASP Non-Human Identities Top 10?

It gives you the inventory and the evidence for several entries, such as improper offboarding, overprivileged identities, reuse and human use of machine identities. It does not fix them by itself; the fixes are role, key and configuration changes your team makes.

Agents often install the same open source packages your services do, and an inventory of agents tends to surface vulnerable dependencies in their MCP servers and tooling. The block below covers how Safeguard closes those gaps once you find them.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It is step 2 and step 3 of the walkthrough above in motion: the assistant signs in as a person, and the tools it can see are the tools your tenant allows.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal, asks it to fix the lodash CVE in a repository, and shows it asking before any command that changes something while it edits package.json, runs npm install and npm test, prints a summary and pushes nothing. It ends with /permissions, which is where you set the level the CLI's own agent works at on that machine.

Click through it at your own pace, or open it full screen.

The third demo is a real Safeguard desktop app session. The CLI session appears in the desktop app's conversation list, the app asks which computer and folder to use, and you approve or deny each command and file edit until the upgrade is done and tests pass. The desktop app is also one of the two places AI agent discovery runs, so it is the app your people will see the consent setting in.

Click through it at your own pace, or open it full screen.

Download the CLI and desktop app at safeguard.sh/download, and read the full product docs at docs.safeguard.sh.

Quick check

Sources

• Safeguard docs: Agents and LLMs
• Safeguard docs: AI agent discovery
• Safeguard docs: MCP tool availability and gating
• Safeguard docs: MCP Integrations overview
• Safeguard docs: Claude
• Safeguard docs: Connector setup
• Safeguard docs: Inference API or MCP server
• Safeguard docs: RBAC, Teams and Organizations
• Safeguard docs: Guard servers and agents
• Safeguard docs: Guard audit trail and alerts
• Safeguard docs: Guardrails and enforcement
• Safeguard docs: Portal audit trails
• OWASP Non-Human Identities Top 10
• OWASP Non-Human Identities Top 10, 2025 list
• OWASP GenAI Security Project: LLM06:2025 Excessive Agency
• Model Context Protocol specification 2025-06-18: Authorization
• Model Context Protocol specification 2025-06-18: Security best practices
• NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST SP 800-207, Zero Trust Architecture
• NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• EU AI Act Article 12, Record-Keeping (text of Regulation (EU) 2024/1689 as reproduced by the AI Act Explorer)
• EU AI Act Article 14, Human Oversight (text of Regulation (EU) 2024/1689 as reproduced by the AI Act Explorer)

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.