Skip to main content
Forge brings cloud and repository machine identities into one inventory while preserving their provider-native identity. Open Identities → NHIs to review service accounts, IAM roles and users, applications, managed identities, repository credentials, and other supported non-human principals.

​
What Forge shows

Each record can include its provider and account scope, native type, status, credential posture, activity, AI relationships, ownership evidence, access, and the source connection that produced the record. Missing evidence is shown as unavailable rather than inferred. The overview deliberately distinguishes scopes. All NHI records counts both provider-native principals and credentials. The attribution cards below it are a mutually exclusive partition of principals only: explicit owner, human attribution, machine attribution, linked with unknown terminal type, or no attribution evidence. Use the displayed principal total when checking that those cards add up. Credential Expiry and provider Lifecycle are separate facts. An Azure certificate can be expired while its parent credential object remains active; that means the expired material still exists in an enabled provider object, not that the certificate can still authenticate. Similarly, an active principal can have no recent activity. Provider actors and contacts are attribution leads. Forge reports an accountable human owner only when the provider record joins to accepted directory, SCIM, email, or person evidence. Bots, applications, deleted users, and login-only records remain machine or unresolved identities. Human-readable labels are shown in attribution paths when Forge has directory or provider evidence. Internal Forge identifiers and provider-native IDs remain available under Identifiers and lineage for API correlation and support, but are not presented as people.

​
Inventory and evidence coverage

Inventory is collected from each connected AWS account, Azure tenant and subscription, Google Cloud project, and GitHub organization. A sync can be complete, partial, stale, permission-blocked, or failed for an individual evidence family. Other successfully collected identities remain available when one provider surface is incomplete. Use the evidence section in an identity drawer to distinguish current provider state from historical activity, accountable ownership from a provider contact, direct grants from inherited access, and an empty result from a permission or retention gap.

​
Native actions

Supported identities can expose provider-native actions such as revoke or disable. An inventory connection never authorizes those actions by itself. Forge enables an action only when a separate operator connection is healthy and the server has an exact target, current before-state, expected provider effect, and independent readback plan. Previewing an action does not change provider state. Execution creates a durable operation and preserves provider acceptance, execution, readback, residual access, and completion as separate facts. If readback cannot prove the expected state, Forge reports the operation as pending or unproven rather than successful.
Disabling a principal or credential may prevent new authentication without ending previously issued sessions or tokens. Review the residual-access result before treating containment as complete.

​
Troubleshooting incomplete inventory

Open the source integration and inspect its latest Test and Sync results. Add only the permission named by the failed evidence family, then run Sync again. A healthy read from one cloud service does not prove that every NHI, activity, credential, or ownership source is readable. Use this sequence for a missing or stale record:
  1. Open Evidence and coverage and note the exact failed fact family, provider scope, observation time, and cannot prove reason.
  2. Open the source integration and compare the latest Test with the latest Sync. Test usually proves authentication; Sync proves individual inventory surfaces.
  3. Run the provider-specific validation command from the integration guide using the same principal and scope as Forge.
  4. Add only the missing API, role, or permission, wait for provider propagation, and run Sync again.
  5. If the provider command succeeds but Forge remains stale, retain the request ID, provider scope, connection ID, and sync timestamp for support.
An empty healthy response and an authorization failure are different states. Forge retains successful evidence families when another family is blocked, so partial inventory should be investigated through its coverage rows rather than treated as a complete connection failure.