KeyForge AI
Non-Human Identity

The population nobody owns — holding production entitlements.

Integration accounts are provisioned by projects, inherited by teams, and reviewed by no one. They outnumber your employees, and they hold real transactional authority.

The problem

Why employee-shaped governance misses them

01

They never leave

No joiner-mover-leaver event ever fires for a service account. It outlives the project, the team and often the vendor that created it.
02

They are rarely owned

Ownership walks out with the implementation partner. When nobody can attest to an account, it gets excluded from certification entirely.
03

The credential is the identity

Whoever can read the secret is effectively that account — so governance has to track who can use it, not just where it is stored.

Coverage

Inventoried across every platform

Each identity gets a named owner, a scope, a rotation schedule and an expiry — then enters the same certification campaign as the people who work beside it.

Oracle EBS

What we inventory

Schema and database accounts, concurrent-program owners, SOA and middleware integration users, and shared administrative logins created during implementation.
Oracle Fusion

What we inventory

Web-service and FBDI/HDL loader accounts, integration cloud connection identities, and users carrying integration roles that quietly hold transactional privileges.
Workday

What we inventory

Integration System Users and the security groups behind them — frequently granted domain access far wider than the integration actually calls.
Service accounts
API keys
Certificates and internal PKI
Workload identities
AI agent credentials
Vaulted privileged credentials

The blueprint

Five steps to continuous NHI governance

Step 1

Inventory relentlessly

Aggregate from directories, cloud IAM, vaults, CI/CD and application service-account tables. Deduplicate by credential, not by name.
Step 2

Assign ownership

Every identity gets a named human owner and a purpose. Unowned accounts follow a defined path: restrict, observe, retire.
Step 3

Right-size the scope

Compare granted scope against actual usage. Peer and usage analysis surfaces the over-privileged tail — usually most of the population.
Step 4

Put lifecycle under policy

Creation through an approved path with an owner and an expiry; rotation on schedule; deactivation when the owning system ends.
Step 5

Watch context, not calendars

Re-evaluate when the owner leaves, the credential appears somewhere new, or the usage pattern shifts.
Outcome

One engine, one rule set

The same policies, owners and expiry rules that govern employees — applied to the identities that outnumber them.
An integration account that can both create a supplier and release a payment is a toxic combination with no human attached. Cross-application segregation of duties applies to non-human identities exactly as it does to people — and far more of them hold that kind of reach.

Can you list every integration account with a named owner?

Most teams cannot. A read-only assessment returns that list for your estate.

Book a Demo →Take the Assessment