> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lumos.com/llms.txt
> Use this file to discover all available pages before exploring further.
# NHI Security for Cloud Platforms
> Inventory every service account, API key, app identity, and AI agent with a human owner on each. Security agents find the exploitable ones and send the fix to the owner.
NHI Security covers the non-human identities (NHIs) your company runs: service accounts, service principals, IAM roles, API keys, and the AI agents built on them. Lumos discovers each identity, assigns it an owner, and identifies the exploitable ones for remediation.
[MCP Governance](/mcp-governance) covers what a person's own AI agent does (e.g. Claude Code, Codex, Copilot).
## NHI Inventory
Every service account, service principal, API key, and workload role in one list, showing where it came from and who is accountable for it.
* **Discover.** Service accounts, keys, app registrations, and agents, from every connected source.
* **Map.** What each one can reach, and which secrets it can read.
* **Own.** The person responsible for it, proposed by Lumos with evidence and confirmed by a person.
* **Retire.** Unused identities and credentials, flagged for removal.
**What the inventory shows**
* Where each identity came from, and what kind it is.
* Whether it is active, and when it was last used.
* What it can reach: its accounts and entitlements, down to the actions and resources.
* Who owns it, and why it exists.
Owner and justification are set once and carry into findings, Access Reviews, and offboarding.
## Threat Detection
Security agents find the exploitable combinations and send the fix to the owner. Broad permissions alone are not a finding. Most of them are intentional. A finding is the combination of these four factors.
* **Privileged.** More power than the job needs.
* **Ownerless.** Nobody accountable.
* **Long-lived.** Credentials that never rotate.
* **Stale.** Unused but still active.
Each finding names the identity, explains which factors combine, and provides the fix with the evidence your team can use to verify it. Findings that fail verification never reach you. The agents run continuously, so an identity becomes a finding the day its owner leaves or its credential ages past your policy.
## What Lumos reads
Here are five NHI connectors to start with, and what Lumos reads from each. Each connector is read-only and separate from the standard integration you may already have for the same system. Lumos reads identity configuration, policy documents, credential metadata, and activity. It never reads secret values, data, or log contents, and it never writes to your environment.
**Microsoft Entra ID** · [Setup guide](/integrations/library/non-human/entra-id-nhi)
| Entity | What Lumos reads |
| - | - |
| Service principals and app registrations | Credential lifetimes and rotation, owner, multi-tenant setup, sign-in activity |
| Directory admin roles | Role assignments held by non-human principals |
| Graph API permissions | Application permissions granted by admin consent |
| Delegated grants | Admin versus user consent, tenant-wide grants, risky scope combinations |
| Conditional access | Policies that cover workload identities, and the gaps |
**AWS** · [Setup guide](/integrations/library/non-human/aws-iam-nhi)
| Entity | What Lumos reads |
| - | - |
| IAM users, roles, groups, and policies | Inline and managed policies, permissions boundaries, last-used activity |
| Trust policies and federation | Who can assume each role, OIDC and SAML providers and their conditions |
| Externally shared resources | Access Analyzer findings for S3, KMS, Secrets Manager, and Lambda |
| Credential hygiene | Unused access keys and abandoned users |
| Compromise signals | GuardDuty findings on non-human principals |
**GitHub** · [Setup guide](/integrations/library/non-human/github-nhi)
| Entity | What Lumos reads |
| - | - |
| GitHub Apps | Installations and the repositories they can reach |
| Personal access tokens | Owner, scopes, last use |
| Deploy keys | Repository and read or write access |
| Actions runners | Registration and the repositories they serve |
**OpenAI** · [Setup guide](/integrations/library/non-human/openai-nhi)
| Entity | What Lumos reads |
| - | - |
| API keys | Organization and project keys, last use |
| Service accounts | Projects and the keys attached to them |
**Anthropic** · [Setup guide](/integrations/library/non-human/anthropic-nhi)
| Entity | What Lumos reads |
| - | - |
| Agents and service accounts | Managed agents, service accounts, and their workspace memberships |
| API keys | Owner, expiry, and whether the key is bound to a person or a service account |
| Workspaces and roles | What each identity can reach, and the roles that grant it |
Lumos adds new NHI connectors regularly. See the NHI connectors page for the current list, or ask your account team about one you need.
## Get started
Lumos enables it per domain.
Setup takes about 30 minutes. The first analysis runs against your real environment as soon as the sync completes.
Confirm or correct proposed owners. Launch each finding's remediation workflow, or dismiss it with a reason. To have findings quote your own rotation or privileged-access policy, upload it to the [Knowledge Hub](/kb/knowledge_hub/knowledge-hub-get-started-guide).
## Frequently asked questions
No. NHI discovery uses a separate read-only connector with different permissions. It sits alongside your existing integration.
The agent builds the fix as a remediation workflow on the finding. An admin reviews and launches it, and the work goes to the owner as a task, with notifications and approvals along the way. The finding completes when the owner finishes the task.
Because it has none to steal. A workload that assumes a role with a short-lived token is the healthy pattern. A long-lived key that never rotates is the problem.