The NHI RFP Framework
A Requirements Matrix and Five Screening Questions for Evaluating Non-Human Identity Platforms
Most identity and access management RFPs inherit their structure from a world of human users — SSO integration, MFA enforcement, HR-driven provisioning and deprovisioning. Service accounts, API keys, and autonomous agents don't fit that shape. They're created by a deploy script rather than an HR system, they don't authenticate interactively, and the person who created one often leaves the company before the credential does. A standard RFP scored against a non-human identity (NHI) platform will pass vendors that look identical on paper and differ enormously in what they can actually discover, attribute, and govern once the contract is signed. This framework breaks the evaluation into four requirement categories and five screening questions designed to surface that difference before procurement is final.
- A rough inventory of the NHI types in your environment — service accounts, API keys, CI/CD secrets, SaaS-to-SaaS OAuth grants, and any agentic AI or MCP deployments already in use
- A shortlist of two or three vendors (the matrix is most useful as a side-by-side comparison, not a single-vendor checklist)
- Representation from security/IAM, platform engineering, and whoever owns your CI/CD and SaaS admin consoles — the five screening questions work best as live demo questions, not written-response items
- The requirements matrix as a working spreadsheet (downloadable below) for scoring each vendor against the same 12 lines
Where standard identity RFPs run out of road
A conventional IAM RFP assumes a directory-centric model: every credential maps to a person in Okta or Microsoft Entra ID, every login is interactive and can be MFA-gated, and offboarding is triggered by an HR event. None of those assumptions hold once you're past human users. A GitHub Actions workflow token, a Lambda execution role, and an OAuth grant connecting Salesforce to a Slack webhook were all created by someone running a script, none of them log in, and none of them appear in any HR system's offboarding workflow when that person leaves.
The practical effect is that a vendor can score "yes" on every line of a generic IAM RFP — SSO support, audit logging, role-based access control — while having no real answer for the questions that determine whether they can find, attribute, and govern the machine identity sprawl already running in your environment. The four categories below are organized around the specific points where that gap shows up, split into Minimum requirements (table stakes — most platforms in this category can do these) and Advanced requirements (the actual differentiators).
The four requirement categories
Each category maps to one operational question: can the platform find everything, can it tell you who's responsible for what it finds, can it handle the identities your AI agents are creating, and does it watch what happens after a credential leaves the vault. The "Advanced" rows in categories 1–4 each correspond to one of the five screening questions in the next section.
1. Dynamic Discovery & Inventory Scope
Objective: locate and index every machine identity and credential across hybrid cloud, on-prem infrastructure, CI/CD pipelines, and third-party SaaS — including the ones nobody registered.
| ID | Requirement | Level |
|---|---|---|
| 1.1 | Vault Bypass Mapping. Discovers active service accounts, tokens, and API keys that exist entirely outside centralized secrets managers. | Minimum |
| 1.2 | Cross-SaaS Interconnectivity. Maps SaaS-to-SaaS machine connections — OAuth marketplace apps, webhook integrations — natively via API, without an inline network proxy. See Question 3 → | Advanced |
| 1.3 | Ephemeral Pipeline Inventory. Tracks short-lived, containerized, or runtime-generated secrets from creation through expiration. | Advanced |
Most platforms in this category can inventory what's already sitting in a vault — that's table stakes. The differentiator is what they find outside it: the OAuth app a developer authorized three years ago, the token baked into a container image, the API key a contractor left in a config file. If a vendor's discovery story stops at "we connect to HashiCorp Vault and AWS Secrets Manager," that's 1.1 without 1.2 or 1.3.
2. Contextual Attribution & Ownership Remediation
Objective: map every discovered credential back to a human owner, engineering team, or business context — including the ones whose creator already left the company.
| ID | Requirement | Level |
|---|---|---|
| 2.1 | Static Directory Matching. Matches resource tags and service account metadata against entries in human identity directories like Okta or Entra ID. | Minimum |
| 2.2 | Heuristic Owner Deduction. For orphaned credentials with no usable tags, parses Git history, IaC configs, and deploy metadata to infer the team that maintains the code calling that token. See Question 2 → | Advanced |
| 2.3 | Safe-Fail Staging. Provides a passive monitoring window (30–90 days) that proves a stale credential is idle before anyone revokes it. See Question 4 → | Advanced |
Discovery without attribution just produces a longer list someone has to triage by hand. 2.1 works fine until the credential's tags are missing or wrong — which, for anything old enough to matter, they usually are. 2.2 and 2.3 are what turn a discovery tool into something a security team can actually act on without breaking production.
3. Autonomous AI & Agentic Governance
Objective: track, audit, and constrain the identities that autonomous AI agents, orchestrators, and Model Context Protocol (MCP) servers create and use on the organization's behalf.
| ID | Requirement | Level |
|---|---|---|
| 3.1 | Static AI Secret Auditing. Finds foundation-model API keys (Anthropic, OpenAI, and similar) hardcoded in environment variables or repositories. | Minimum |
| 3.2 | Dynamic Multi-Hop Lineage. Traces the inheritance chain of ephemeral sub-tokens an AI orchestrator (LangChain, Copilot Studio, custom agents) spawns mid-task. See Question 5 → | Advanced |
| 3.3 | Least-Agency Enforcement. Validates downstream MCP node trust and constrains agent boundaries against OWASP ASI03 (Identity and Privilege Abuse). See Question 5 → | Advanced |
3.1 is a string-matching problem most secret-scanning tools already solve. 3.2 and 3.3 are where this category actually lives — an agent's session token isn't one credential, it's a chain of credentials the agent mints for itself as it works, and a platform that can't follow that chain can't govern it. The OWASP agentic AI identity controls guide covers ASI01–ASI03 in more depth if this category is where most of your evaluation time should go.
4. Runtime Posture & Behavioral Analysis (NHIDR)
Objective: move beyond static posture scans to continuous behavioral baselines and active machine-identity threat detection and response.
| ID | Requirement | Level |
|---|---|---|
| 4.1 | Entitlement Right-Sizing. Compares assigned permissions against actual historical usage to flag over-privileged accounts and propose minimized policies. | Minimum |
| 4.2 | Continuous Behavior Baselines. Analyzes network and infrastructure telemetry to flag runtime credential misuse after a token leaves the vault. See Question 1 → | Advanced |
| 4.3 | Asynchronous Log Reconciliation. Reconstructs unified identity lineage graphs across multi-cloud environments even when logs arrive late or out of order. | Advanced |
4.1 is posture management — comparing what's granted to what's used, at rest. 4.2 is the line into detection and response: what the platform does while the credential is live and in use. A vendor can be excellent at 4.1 and have nothing at all for 4.2; the two get marketed as if they're the same capability, and they aren't.
Five questions that separate platforms from feature-washed point tools
Each question below maps to one of the Advanced requirements above. They're written to be asked live, in a demo or technical session — not submitted as written RFP line items. A written "yes" to "do you support X" costs a vendor nothing. Walking through the actual architecture in front of your team costs them the ability to bluff.
Question 1 — How does it track a credential after it leaves the vault?
"Once a token is checked out of [your secrets manager] and sitting in an application's active memory, how does your platform monitor what it does next, and how would it detect anomalous use?"
- Explicit description of an NHIDR-style architecture — detection and response, not just posture
- Ingestion of secondary telemetry: VPC flow logs, CloudTrail, API gateway events
- A behavioral baseline per credential — what "normal" looks like for this specific token
- Concrete examples of anomalies it would flag: bulk queries, access from a new region, off-hours activity
- The answer is entirely about vault checkout logging or rotation schedules
- "We enforce 90-day rotation" offered as the answer to a question about runtime behavior
- No mention of any telemetry source outside the secrets manager itself
Question 2 — How does it find an owner for an orphaned credential?
"When you discover a shadow service account whose creator has already left the company, how does your platform determine who owns it now?"
- A cross-system relational engine: Git blame, IaC configs, pipeline commit metadata, CMDB
- A ranked suggestion of the team that actively maintains the code calling that token
- Logic that works even when the account's name doesn't match any naming convention
- "Your team assigns ownership manually in our dashboard" is the entire answer
- Owner matching relies on exact string-matching against directory account names
- No mention of source code, IaC, or pipeline metadata as inputs
Question 3 — Can it see SaaS-to-SaaS connections without a network proxy?
"Can you map an OAuth token connecting [Salesforce] to [Slack] or a GitHub repository — end to end — without sitting inline on the network?"
- Direct API-level access to marketplace consent records and OAuth scopes from each SaaS tenant
- A connection graph spanning multiple SaaS platforms, not just cloud infrastructure accounts
- No requirement to route traffic through an appliance, agent, or browser extension
- Visibility stops at the AWS/Azure/GCP boundary or container runtime
- SaaS-to-SaaS mapping requires installing a proxy, CASB agent, or browser extension
- "We can see it if it shows up in your SSO logs" — most app-to-app OAuth grants never do
Question 4 — What proves a stale credential is actually safe to kill?
"Before I revoke this credential, what evidence does your platform give me that it's actually unused — and over what time window?"
- A defined rolling observation window (30, 60, or 90 days) with zero-usage confirmation across it
- A simulated or staged revocation step before the real one executes
- An audit trail of the evidence, suitable for a change-management ticket
- An immediate delete/revoke button with no historical verification
- "Revoke it and see what breaks" offered as the methodology
- No rolling window — just a single point-in-time usage check
Question 5 — How does it govern AI agents and MCP servers?
"Walk me through what happens in your platform when an AI orchestrator spins up a new MCP connection and mints a session token to call three different internal systems."
- Recognition of orchestrator footprints (LangChain, Copilot Studio, custom agents) as a distinct identity class
- Tracing of the parent-to-sub-token inheritance chain as it's created
- Least-agency constraints — time-bound, scoped, revocable — applied to the agent's downstream access
- Explicit reference to OWASP Agentic AI risk categories, especially ASI03
- "An AI token is just a string — our database treats it like any other API key"
- No distinction between a long-lived service account and an ephemeral, multi-hop agent session
- No way to constrain or time-box what an agent's minted tokens can do downstream
For more on what "good" looks like for category 3 specifically — including how ASI01 through ASI03, ASI04, and ASI07–ASI10 map to concrete architectural controls — see the OWASP agentic AI identity controls guide.
Turning this into an RFP
The cleanest way to use this matrix is to treat the Minimum requirements as pass/fail gates — a platform that can't do 1.1, 2.1, 3.1, and 4.1 isn't a serious candidate for this category, regardless of what else it offers. Score the Advanced requirements on a scale (0–3 works well: no capability, roadmap only, partial/manual, native and automated) rather than pass/fail, because most vendors will land somewhere in the middle and the gradient is the useful signal.
Run the five screening questions as a live technical session with every vendor on your shortlist, using identical phrasing each time. Written RFP responses are useful for the Minimum rows, where the answer is close to binary. For the Advanced rows and the five questions, the value is in watching how a vendor's solution architect responds in real time — whether they can go two layers deeper than the marketing deck, or whether the conversation quietly redirects back to rotation policies and dashboards.
If you're evaluating against compliance frameworks alongside this matrix — SOC 2, NIST 800-53, PCI DSS 4.0.1, ISO 27001:2022, the EU AI Act, or DORA — the NHI audit and compliance mapping guide shows how categories 2 and 4 in particular map to specific control citations auditors will ask about.
The full requirements matrix — all 12 items, organized by category, with the Minimum/Advanced split and columns for capability level, vendor response, and architecture notes across up to three vendors — is available as an editable spreadsheet. Drop in your shortlist and score every vendor against the same 12 lines.
Related: the compliance landscape page covers the broader shift toward continuous machine accountability referenced in categories 2 and 4. The vendor index notes which platforms have native architecture for the Advanced requirements above versus partner-dependent or roadmap capabilities.