Most identity products model a non-human caller as a user with a strange address and no password. It works, in the sense that tokens come out. It fails everywhere else. You cannot answer what the agents did last night, because "agent" is a naming convention. You cannot revoke all of them, because they are not a set. You cannot tell, looking at a directory, which rows are people.

What SkipAuth does

An identity has a type: person, service or device. The authorization model does not change between them, which is the point: a service account has functional roles, scopes and resolved entitlements exactly as a person does, and the same inspector answers the same question about either.

What differs is credentials, and what a credential should be depends on what is holding it:

Certificates, for anything that can hold one. A built-in certificate authority issues X.509 certificates for services and devices, which is the right credential for a caller that lives somewhere you control.
API keys, for callers where a certificate is impractical, held per device.
Delegated tokens with a named audience. When an application acts on behalf of a caller, the token it receives says who it may present itself to. That audience is checked at issuance and again at the edge.
A role bound to a task, not to the identity. An elevated grant can belong to the piece of work that needed it rather than to the agent, carried on a delegated token with its own audience and its own expiry. That is what makes it something you can account for afterwards.

And a colour. Machine identity has one colour throughout the console, and nothing else is allowed to use it. A row carrying that edge is a row where a machine is holding the token. That sounds like a design detail until you scan a directory of four hundred rows looking for the ones that are not people.

How to check it

Create a service account and link it to an application. Give it a functional role with a scope.
Mint a token with client credentials and read it. The entitlements and role paths should be there, resolved, exactly as they would be for a person.
Ask the resolved-permission inspector about the service account. It should answer the same way it answers for a person.
Issue a certificate from the built-in authority to a device identity, then revoke it, and confirm the caller stops.
Open the identity list and look at it, not at a filter. The machine rows should be obvious.

Where it stops

It is not a secrets manager. SkipAuth issues, holds and revokes the credentials that identify a caller to SkipAuth. The third-party keys your application needs in order to do its job are a different problem, and a vault is the right tool for them.

A type is not a permission. Marking a caller as an agent tells you what it is, not what it may do. What it may do is the role graph, and the useful property is that the graph does not care: an agent is authorised exactly the way a person is.

A certificate has to get to the caller. The built-in authority issues and revokes them. Placing one on a device, and replacing it when it rotates, is your deployment's job, the same as any other material you distribute to a fleet.

Governing what an agent's tools may do is a different product. This governs identity: who the agent is, what it may hold, and what it is allowed to reach. The question of which actions a tool call may take on the other side of that boundary is a separate problem, and at Parallel Labs it is a separate product.

What the alternatives ask of you

Approach	What it asks of you	SkipAuth
A service account that is a user with no password	Encode the distinction in a naming convention, then rely on it in every query and every report.	Type is a property of the identity, so the question is answerable without a convention.
A secrets manager holding machine credentials	Manage credentials in one system and authorization in another, and reconcile them by hand.	One identity, with its credentials and its roles in the same place.
A separate workload identity product	A second system, a second model, and a seam between people and machines.	The same authorization model over both, and a colour that tells them apart.
Long-lived keys in configuration	Rotate them never, and find them in a repository later.	Certificates with a lifecycle, and tokens with a narrow audience and an expiry.