Accountable
Every action has an actor
Service, machine and system identities each appear in audit records as themselves, alongside the person who used them where one did.
Platform / Identity model
Identity Types
Not every identity is a person signing in. WebFrolic has four identity types — regular, service, machine and system — so integrations, automation and AI agents get their own accountable identity instead of borrowing someone’s password.
Available now in WebFrolic.
Why it matters
Shared accounts and personal keys erase accountability.
When an integration uses an employee’s password, or several people share one admin login, nobody can say who acted, and removing one person breaks the integration. Separate identity types keep every action attributable and every credential owned.
Fewer credentials
Credentials only where needed
Only regular and machine users hold credentials. Service and system users have none to steal or share.
Fail-safe
Access that survives a departure
Integrations and emergency access hang off service users, not individuals, so a leaver does not take a critical job down with them.
The four types
Who signs in, who is assumed, and who acts directly.
| Type | Credentials and sign-in | Use it for |
|---|---|---|
| Regular | Has credentials and signs in. Can be a customer, employee or administrator. | Every person who uses your applications or the WebFrolic dashboards. |
| Service | No direct credentials. Assigned to regular users, who assume it to act as the service user. | Integrations, shared operational jobs and fail-safe access such as emergency administration. Service users. |
| Machine | Belongs to an OAuth2 application. Acts directly with client credentials, or on behalf of a user after the user consents and an access token is issued. | Back-end services, scheduled jobs, and agents acting for a user. OAuth2 secrets · Connections. |
| System | Created by the identity provider. No credentials, cannot be impersonated, and cannot be assigned OAuth2 secrets. | The platform’s own API capabilities for interacting with WebFrolic. |
Choosing a type
Three questions decide it.
Is it a person?
Use a regular user
Give the person their own account, persona and authenticators. Never share it.
Is it a shared job?
Use a service user
Assign it to the named people who run the job. They assume it when needed, and the record shows who did.
Is it an application?
Use a machine user
Register the OAuth2 application. It acts with client credentials, or for a user once that user consents.
In the console
Set it up in four steps.
Menu names match the WebFrolic console. The setup guide has the detail.
Inventory non-human access
List integrations, scripts, agents and shared logins, and who owns each.
Move shared work to service users
Create a service user for each shared job, give it only the roles it needs, and assign it to its owners.
Register applications
Create OAuth2 applications for services and agents so they run as machine users with their own credentials and scopes.
Retire the old credentials
Remove shared passwords and personal keys that the new identities replace, and check the audit trail shows the new actors.
Before rollout
Questions worth answering.
Settle these first and the rollout is mostly configuration.
- Find every place an integration signs in with a person’s credentials.
- Name an owner for each service user and machine user.
- Decide which regular users may assume each service user.
- Restrict where service and machine users may operate with network rules.
- Confirm audit records show both the person and the service user they assumed.
Related capabilities
Explore what connects to this.
These capabilities are usually configured together.
Evaluate with your scenario
Start with a concrete workflow.
Share the identities, resource boundary and decision you want to test. The walkthrough can focus on the relevant behavior rather than a generic feature tour.