Identity model

Forge keeps identities separate when they represent different security boundaries. Select the identity type based on where the principal exists and what it needs to authenticate to.

​

Provider-native NHIs

Provider-native NHIs are discovered from connected cloud and repository systems. Forge preserves the provider’s identity, account scope, credentials, access, activity, and available ownership evidence. Inventory does not create or silently take control of the provider principal. Use Identities → NHIs when you need to investigate an existing machine identity, find unowned access, or perform a supported provider-native action. See Non-human identities.

​

Agent identities

An Agent identity is the durable Forge identity for one autonomous workload. It records ownership and lifecycle independently from any cloud role or repository credential. Enrolled runtimes authenticate to Forge, and supported provider access is assigned through bounded access profiles. Use Identities → Agents when the workload needs its own Forge lifecycle, runtime enrollments, or keyless provider access. See Agent identities.

​

Gateway service accounts

An LLM Gateway service account authenticates a server-side application to Forge’s model routes. Its keys belong to the calling workload and should be scoped, rotated, and stored like any other application credential. The service account does not become a provider-native NHI or an Agent identity merely because it generates AI activity. Use this identity when a service needs LLM Gateway routes, model access, budgets, and content policy without a signed-in human. See LLM Gateway.

​

Forge API and MCP service accounts

Forge API and Forge MCP service accounts authorize automation that manages or queries Forge. Assign only the organization permissions required by the automation. These credentials do not authorize an upstream model, cloud provider, or Registry MCP server unless that access is configured separately. See Roles, REST API, and Forge MCP.

​

Relating identities without merging them

One workload can legitimately have several related identities. For example, an Agent identity can enroll a runtime, use an AWS role discovered as an NHI, and call LLM Gateway with a service-account key. Keep those principals separate so their credentials, owners, permissions, and revocation paths remain clear.