The market for AI agent identity and security tools is crowded, fast-moving and full of overlapping claims. Established IAM, IGA, PAM and secrets management vendors have added agent features; NHI security specialists have extended into agents; new companies focus only on agent identity, MCP gateways or agent runtime security. Many products do part of the job well and describe themselves as doing all of it. This vendor-neutral buyer's guide helps you define what you need, compare products on the capabilities that matter, ask questions that separate substance from positioning, and run a proof of concept that tests real risks.
Key takeaways
- Start from your use cases and maturity, not from product categories. See the Agentic AI Identity Maturity Model.
- Most organisations need capabilities across discovery, identity and credentials, authorisation, tool and MCP control, monitoring and response, and governance. Few single products cover all of them well.
- Prefer products that build on open standards (OAuth, OpenID, SPIFFE, MCP, A2A, AuthZEN) and integrate with your existing identity provider, IGA and SIEM.
- Test with your own agents and attack scenarios during a proof of concept, not a vendor demo environment.
Step 1: Define what you are solving
Write down the use cases before speaking to vendors. Typical ones:
- Finding shadow AI: OAuth-connected AI apps, AI API keys, low-code agents and MCP servers.
- Giving internal agents their own identities and removing static and human credentials.
- Controlling what agents can do at tool and API level, including human approval.
- Securing MCP servers and developer use of coding agents.
- Governing agents built on third-party platforms (productivity suites, CRM, IT service management).
- Detecting and stopping misbehaving or compromised agents.
- Producing evidence for audit and regulation.
For each, note the agent platforms, clouds, identity providers and SaaS systems involved, and which teams own them.
Step 2: Understand the capability areas
| Capability area | What it does | Key questions |
|---|---|---|
| Discovery and inventory | Finds agents, AI integrations, OAuth grants, API keys and MCP servers; maintains a registry with owners | Which sources does it read? How does it link an agent to its credentials and owner? |
| Agent identity and credential issuance | Issues unique, short-lived identities and tokens to agents; brokers credentials so agents do not hold secrets | Which identity standards does it use? Does it replace static secrets or just store them? |
| Delegation | Lets agents act for users with scoped, attributable authority | Do downstream systems see both the user and the agent? How is authority narrowed across hops? |
| Authorisation and policy | Decides per action whether an agent may proceed; enforces approval for high-impact actions | Where is policy enforced? Can it use context such as data classification and behaviour? |
| Tool and MCP gateway | Mediates agent access to tools and MCP servers; enforces allowlists, scopes and logging | Does it implement the MCP authorisation specification? Does it detect tool definition changes? |
| Runtime monitoring and detection | Baselines agent behaviour; detects misuse, injection and credential abuse | What signals does it use? How are alerts attributed to agent and user? |
| Response and containment | Stops agents and revokes credentials quickly | How long does revocation take across all systems? Is it per agent? |
| Governance and lifecycle | Ownership, access reviews, change review and retirement for agents | Does it integrate with our IGA process? How are orphaned agents handled? |
| Posture and compliance | Assesses configuration risk; maps controls to frameworks; produces evidence | Which frameworks are mapped? Can evidence be exported for audit? |
Step 3: Evaluation criteria
Coverage
- Which agent platforms, frameworks, clouds, SaaS platforms and identity providers are supported today, as opposed to on the roadmap?
- Does it cover agents you build, agents in third-party platforms and AI apps connected by users?
- Does it cover both local and remote MCP servers?
Depth of identity controls
- Does it remove long-lived secrets, or only vault and rotate them?
- Can it bind credentials to specific agents and tasks, with short lifetimes?
- Does delegation preserve both user and agent identity end to end?
- Is authorisation evaluated per action, with context?
Standards and interoperability
- Support for OAuth 2.0 and 2.1, token exchange (RFC 8693), sender-constrained tokens (mTLS or DPoP), SPIFFE and workload identity federation.
- Conformance to the current MCP authorisation specification; support for A2A where relevant.
- Use of standard interfaces for policy decisions (such as OpenID AuthZEN), signals (Shared Signals and CAEP), logging and SIEM export.
- Integration with your identity provider, IGA, PAM, secrets manager, SIEM and ticketing.
Operational fit
- Deployment model (SaaS, self-hosted, hybrid) and where agent data, prompts and logs are processed and stored.
- Added latency on agent tool calls, and behaviour if the product is unavailable (fail open or fail closed).
- Effort for developers to adopt: SDKs, sidecars, gateways or no-code integration.
Vendor security and viability
- How the vendor protects the credentials and tokens it holds, which make it a high-value target.
- Certifications, penetration testing, incident history and disclosure practices.
- Whether customer data or prompts are used to train models.
- Roadmap credibility and financial position in a consolidating market.
Step 4: RFP questions that reveal substance
- Show how an agent in our environment moves from a static API key to a short-lived credential with your product. What remains stored, and where?
- When an agent acts for a user, what exactly does the downstream API receive? Show us the token.
- An agent is hijacked by indirect prompt injection and attempts a destructive action with valid credentials. What in your product stops it, and where is that enforced?
- How do you discover an MCP server a developer installed locally with a personal access token in its configuration?
- How long does it take to revoke all credentials and grants for one agent across every connected system? Demonstrate it.
- How do you detect a change in an MCP server's tool definitions after approval?
- What happens to an agent whose owner leaves the organisation?
- Which of your features depend on draft standards, and what is your plan if those drafts change?
- Which OWASP Agentic Top 10 and OWASP NHI Top 10 risks do you address, and how would we verify it?
Red flags
- "Guardrails" that rely only on prompt filtering or model-based classification, with no enforcement at the credential or tool layer.
- Agent "identities" that are static API keys issued by the vendor.
- Delegation that passes the user's token through to other services.
- Discovery limited to a single platform or cloud.
- No clear answer on how the vendor secures the credentials it brokers.
- Roadmap items presented as current capabilities.
Step 5: Run a meaningful proof of concept
- Pick two or three real agents, including one that acts for users and one with access to sensitive data or destructive actions.
- Define success criteria in advance: secrets removed, per-agent attribution in logs, time to revoke, false positive rate, added latency and developer effort.
- Run attack scenarios: indirect prompt injection through a document or email; an agent trying to use a credential it was not issued; a changed MCP tool definition; an attempt to exfiltrate data through a second tool.
- Test failure modes: what happens when the product is unavailable, and when an agent is revoked mid-task.
- Involve the people who will run it: IAM, platform engineering, developers and the security operations centre.
Build, extend or buy
- Extend what you have: many identity providers, IGA and secrets platforms now support parts of agent identity. This can be the fastest route for inventory, ownership and credential issuance.
- Add specialist tools: for discovery across SaaS and developer environments, MCP gateways and agent runtime monitoring, specialists are often ahead.
- Build: platform teams can assemble workload identity, token exchange, a policy engine and a gateway from open source and cloud services. This gives control but requires ongoing engineering.
Most organisations will combine all three. The important thing is that the pieces share one agent inventory and one source of policy.
Practitioner checklist
- Document use cases, platforms and current maturity before engaging vendors.
- Map required capabilities to the areas above and identify which existing tools already cover them.
- Weight evaluation towards enforcement at the credential and tool layers, standards support and integration.
- Use the RFP questions to test claims with demonstrations, not slides.
- Run a proof of concept with real agents, defined success criteria and attack scenarios.
- Assess the vendor's own security, given the credentials it will hold.
How NHI Mgmt Group can help
We provide independent market analysis, RFP strategy and evaluation support for NHI and agentic AI identity programmes. Browse vendors in our NHI and AI products directory or contact us about independent evaluation support.
Related NHI Mgmt Group resources: Agentic AI Identity Maturity Model · Agentic AI Identity Guide · MCP Security Guide · Agent Identity Standards Tracker
