Identity & Access
How AI tools and agents authenticate, who owns them, and whether their credentials are short-lived and scoped.
API tokens with unrestricted scope
Admin API tokens granted the all scope. Target: 0.
Why it matters. A token with every scope works like a permanent admin password. If someone leaks it, the attacker gains access to your whole organization, not just to one feature.
How to improve it.
- Create a replacement token with only the scopes the caller actually uses.
- Update the consumer, confirm it works, then revoke the broad token.
The panel links to API Tokens.
Framework mapping: OWASP NHI NHI5 Overprivileged NHI · NIST CSF PR.AA-05
MCP connections on API keys instead of OAuth
Active gateway integrations that authenticate with a single shared API key. Willow counts an integration only if a group gives human users access to it. Target: 0.
Why it matters. Anyone who holds a shared key can use it. The key does not identify a user, it never expires, and the only way to revoke it is to replace it everywhere it is used. When several people share one key, all of their tool calls look identical in the audit log, so you cannot tell who made each call. A key that only machine users can reach is a normal service account, so Willow does not count it here.
How to improve it.
- Remove the human members from the groups that grant the integration, leaving it to machine users only.
- Instead of step 1, you can switch the integration's authentication type to API key per user. Each person then supplies their own key, and the audit log shows who made each call.
- If the connector supports OAuth, use OAuth instead. OAuth credentials expire, you can revoke one user's access without affecting others, and the audit log shows who made each call.
See Configure authentication and Authentication modes.
Framework mapping: OWASP NHI NHI4 Insecure Authentication · NIST CSF PR.AA
SSO not configured or not enforced
This KPI counts two problems. The first is that no SSO provider is connected. The second is that an SSO provider is connected, but users can still sign in another way. Target: 0.
Why it matters. If you do not enforce SSO, your AI access control is separate from your identity provider. When an employee leaves and you disable their directory account, they keep their access to AI tools.
How to improve it.
- Connect your identity provider under Settings > Authentication Settings, then verify a test login.
- Turn on SSO enforcement so password login is rejected.
- Enable the approved-clients restriction so only registered MCP clients can reach the gateway.
See Configure SSO and Security Settings.
Framework mapping: NIST CSF PR.AA-01 · SANS Access Controls
Unmanaged MCP servers carrying static credentials
Partial coverage
MCP servers found on employee devices. Willow counts a server when its configuration file holds an API key, a token, or a password in a header or an environment variable. Target: 0.
Why it matters. These credentials sit in plain text in configuration files on laptops. Your gateway does not protect them, and nobody rotates them. Anyone with the file, or any agent that can read it, has the credential.
How to improve it.
- Open a server in the list and read the credential. Each finding names the header or environment variable that holds the credential, and links to the page where you can revoke it.
- Rotate the credential at the provider, then mark it as rotated here. Assume that any credential found in a device configuration file has already leaked.
- Block the server. The scan agent then removes it from devices. Add the server again as a managed integration behind the gateway, using OAuth, so that each user signs in with their own account.
- Some fields only look like credentials, for example an API version header or a public identifier. Mark these as not a secret so Willow stops counting them.
See The AI Discovery dashboard and Vault.
Framework mapping: OWASP NHI NHI2 Secret Leakage · OWASP NHI NHI4 Insecure Authentication · NIST CSF PR.AA
Credentials unrotated for over 90 days
Vault secrets and machine-user client credentials whose last rotation was more than 90 days ago. Target: 0.
Why it matters. The longer a secret stays in use, the longer an attacker can use it after it leaks. Most leaked credentials are discovered a long time after the leak, and a key that was never rotated still works on the day you discover it.
How to improve it.
- Rotate each secret in Vault. Any integration that uses the
{{vault.NAME}}reference picks up the new value automatically. - Rotate machine-user client secrets from the machine users page.
- Put a recurring rotation reminder on anything you cannot automate.
Framework mapping: OWASP NHI NHI7 Long-Lived Secrets · NIST CSF PR.AA-01
Agents without a named owner
Background agents with no owner assigned. Target: 0.
Why it matters. If an agent has no owner, nobody reviews its permissions and nobody is notified when it does something wrong. The agent is also not linked to any employee, so it stays active after that employee leaves.
How to improve it.
- Assign an owner to each agent from the list, or from the background agents page.
- Disable any agent that nobody claims. If nobody will take responsibility for an agent, it has no current business purpose.
Framework mapping: NIST AI RMF GOVERN 1.6 inventory · ISO 42001 A.3.2 roles
OAuth grants outside an approved client list
approximate
Active OAuth grants held by client applications that match none of your enabled AI tools. The score counts each grant, and the list groups the grants by client. Target: 0.
Why it matters. An approved AI tool is one that somebody in your organization reviewed. Any other client with an active grant got access because a real user approved it, without that review. This is how the confused deputy problem happens: the client uses a trusted user's permissions to reach your tools. It is also why a grant can stay active long after the user stopped using the tool.
How to improve it.
- Work through the list one client at a time. If you recognize a client, add its redirect URI to an AI tool under Manage > AI Tools. The client then counts as approved.
- Revoke the grants belonging to clients you do not recognize, then enable the approved-clients restriction so they cannot come back.
- Loopback clients, which redirect to an address on the same machine such as
localhost, are always exempt from this restriction. For each loopback client you keep, set a client name pattern on its AI tool. Do not rely on the redirect URI alone.
See AI Tools and Security Settings.
Framework mapping: OWASP NHI NHI3 Vulnerable Third-Party NHI · MCP Spec Confused deputy