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 Gateway.Forge service accounts
Forge service accounts authorize automation that manages or queries Forge. Assign only the organization permissions required by the automation. A service account with theresources:connect scope can also be selected in Resource
Policies and credential assignments and exchange its Forge token for a
short-lived Resource access token. 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.
Resource identities
Resource Policies use the identity authenticated by the managed device or Resource Gateway. A person is evaluated through the bound directory user and current groups. A non-interactive caller uses an active Forge service account with theresources:connect scope.
Forge does not infer an Agent identity from a process observation.
Resource credentials can be assigned to a user, group, service account, or a
default. Those assignments choose how Forge authenticates to the destination;
they do not merge the destination account with the caller’s Forge identity.
For RDS and Aurora PostgreSQL or MySQL, that authentication can be a temporary password generated
from the Resource Gateway’s AWS workload identity instead of a stored secret.
For HTTP APIs, Forge can exchange an assigned OAuth client secret for a
short-lived bearer token after policy allows the request. Where the upstream
identity provider supports OAuth 2.0 token exchange, the Gateway can instead
exchange the caller’s signed Forge Resource token without storing an upstream
secret; this preserves the individual user or service-account identity at the
provider boundary. The caller remains
the same Forge user or service account; the upstream database user, API key,
OAuth client, or cloud role is an access method assigned to that caller, not a
second person or agent record.
Credential selection is deterministic: an exact service-account assignment
wins over an exact user assignment, which wins over one unambiguous group and
then the default. Multiple matching group credentials or duplicate names that
cannot be resolved to exactly one identity fail closed. Disabled and
cross-organization identities are never eligible.
Resource approval grants remain bound to the authenticated Forge identity,
device and process when available, Resource, exact operation, and matching
policy revisions. Changing any of those requires another decision; the
brokered destination credential does not become the approval subject.
See Resource Policies.