When teams need authentik agent accounts for automation
Use an authentik agent account when a script or AI agent needs API access and the access should follow a specific person's permissions. Teams usually reach this point when automation has to read or change authentik objects, and the team must decide whose access the automation inherits. In authentik 2026.8, agent accounts are a service account type that acts on behalf of a parent user when it calls the authentik API. The parent user's policy access is inherited, expiration rules can limit how long the automation remains valid, and audit events record the activity. The feature is listed as Enterprise, and the authentik pricing page splits editions so that Open Source does not include it, so a team on the open-source edition should not plan around it.
The decision is less about creating a token and more about whom the automation should represent. A parent user with broad administrator rights passes those rights to every agent acting for them, so the parent should be a narrowly scoped operator account, not a daily-use administrator. Confirm with authentik which API operations an agent account can perform, how inherited policy access is switched on or off, and how expiration is set and renewed. Also confirm what the audit events contain and whether they are forwarded to your log platform, because an agent that acts under a human's name will show up in that person's activity unless the events say otherwise.
Before committing, compare agent accounts with a plain service account that holds its own permissions. A service account is simpler to reason about for fixed jobs, but it does not follow a parent's changes in access. An agent account ties the automation to a person's lifecycle, so offboarding that person affects the agent too. Ask your authentik partner or account team to confirm these behaviors in your target version, and review the authentik 2026.8 release notes before you design the parent, expiry and audit model.
Agent accounts compared with plain service accounts
This table compares authentik agent accounts, an Enterprise feature added in 2026.8, with plain service accounts used for scripts and integrations. Read each row as a question to answer for your own tenant, and keep items marked to confirm open until you test them in a non-production instance. The main takeaway is that agent accounts take their access from a named parent user, so inherited policy and expiry rules become the controls to review first.
| Area | Agent account | Plain service account |
|---|---|---|
| Identity source | Acts on behalf of a parent user, so that user's identity anchors the access | A standalone account created for a script or integration, not tied to a person |
| Inherited policy access | Inherits access from the parent user, with controls over that inheritance (confirm options) | Access is set directly on the account through its own groups and policies (confirm) |
| Expiry rules | Expiration rules can limit how long agent access lasts (confirm available settings) | Access and tokens persist until someone rotates or removes them (confirm token settings) |
| API management | Created and governed for API calls to authentik (confirm where controls sit in the admin interface) | Created and governed for API calls, with credentials you issue and rotate (confirm) |
| Audit attribution | Audit events link actions to the agent and its parent user (confirm event fields) | Actions are recorded under the service account name (confirm event fields) |
| Licensing | Enterprise feature per the 2026.8 release notes | Confirm edition requirements against the pricing page before planning |
| Offboarding impact | Confirm whether deactivating the parent also ends agent access and tokens | Survives a person's departure, so it needs a named owner and periodic review |
| Fit for AI agents | Suits agents that must act within a user's scope and lose access when that user's access changes (confirm) | Suits fixed, narrow integrations with stable permissions and a clear owner |
Setting up an agent account step by step
This sequence takes an agent account from license and version checks through scoped access, credential handling and audit verification, so each step ends with evidence you can review before automation runs in production.
Confirm the Enterprise license and version
Confirm that your authentik deployment is on a 2026.8.x release and that the Enterprise license covers agent accounts, since the feature is listed as Enterprise in the 2026.8 release notes. Check the running version in the admin interface and compare it against the supported versions in the authentik security policy. Ask your license contact to confirm that the license applies to the instance you will use for automation. Done means you have a written record of the version, the edition and the license holder, stored with the change request.
Choose the parent user and its groups
Pick the human user the agent will act for, and review that user's group memberships, applications and policy bindings. Because the agent inherits access from its parent, a broad parent means a broad agent. Where possible, use a parent who holds only the access the automation needs, and consider a dedicated owner account rather than a personal administrator account. Record who owns the parent, who approves the agent and what each group grants. Done means a short access map exists that your security reviewer has signed off.
Create the agent account
Create the agent account in the authentik admin interface following the agent accounts documentation in the 2026.8 release notes, and link it to the chosen parent user. Give it a name that identifies the automation and its purpose so later audit entries are easy to read. Do not reuse an existing human account or a generic shared name. Done means the account appears in the directory with the parent relationship visible, and you can read its details without error.
Set inherited policy scope and expiry
Configure which policies and application access the agent inherits from its parent, and set an expiration rule that matches the lifetime of the automation. Confirm the inheritance controls in the release notes and in your own instance, because the exact options determine what the agent can reach. Test the boundary by checking an application the parent cannot open, which the agent should also be unable to open. Done means the scope matches the access map from the previous step and the expiry date is recorded in your change ticket.
Issue and store the API credentials
Generate the API token for the agent through the authentik API management controls, and choose the narrowest token lifetime your automation can tolerate. Store the token in your organization's secrets manager with restricted read access, never in source code, shared chat or a shared document. Record the secret location, the rotation owner and the revocation procedure. Done means the token exists only in the secrets store, the owner has confirmed the storage path, and you can revoke it in a test.
Test API calls with the agent identity
Run a small set of read-only API calls with the agent token, such as listing the objects the parent can see, and confirm the responses match the scope you set. Then attempt one call the agent should not be allowed to make and confirm it is refused. Keep the test scripts short and versioned so they can be rerun after upgrades. Done means each allowed call succeeds, each denied call fails as designed, and the results are saved with the change record.
Confirm audit events for agent actions
Open the authentik event log and find the entries created by your test calls. Confirm that each entry identifies the agent account and the parent user, and that the actions are visible with timestamps. Check that your log forwarding or retention setup keeps these entries for the period your policy requires, and confirm that enhanced audit logging is included in your edition as listed on the pricing page. Done means you can trace one test action from the API call to the audit record, and your reviewer accepts the evidence.
Security risks of delegated API access for agents
Delegated agent access inherits the reach of a real user, so each risk below starts from the parent account. The cards pair every risk with the control that limits it and the check to run before an agent receives a token.
Over-broad inheritance from a powerful parent
An agent account acts on behalf of a parent user, so it can reach whatever that user can reach through the authentik API. A parent who administers applications, groups or flows hands those rights to every script it spawns. Scope the parent to a dedicated automation user with the smallest policy access the task needs, and confirm in the 2026.8 controls which inherited policy access is switched on. Review the parent's group memberships before issuing any agent account.
Credentials that outlive their purpose
A token issued for a one-time migration or a pipeline that was retired can keep working long after its owner has moved on. Agent accounts add expiration rules, so every agent should have an end date set at creation. Ask who approves a longer lifetime and whether expiry can be renewed only through a deliberate review. Set an expiry on every agent account, including test accounts.
Attribution gaps across shared parents
When many agents share one parent user, audit entries show the parent's name for every automated action, and an investigator cannot tell which script or model made a change. Give each agent its own account with a clear name that identifies the job, owner and environment. Then check that audit events record the agent account as the actor, not only the parent. Name agents by job, owner and environment.
Secret storage for issued tokens
An API token is a bearer credential, so anyone who reads it can act as the agent until it expires. Tokens copied into CI variables, prompt configurations, local files or chat logs are a common leak path. Store each token in a dedicated secrets manager, restrict read access to the one workload that needs it, and rotate it when the workload changes owners. Never place agent tokens in prompts, source code or shared logs.
Missing review of agent activity
Issuing an agent account is not a control unless someone reads what it did. Export and review audit events for agent accounts on a fixed schedule, and compare the actions with the job the agent was approved to perform. Unexpected policy changes, group edits or bulk reads should trigger a revocation and an incident review. Schedule audit review before the agent goes live.
Plain service accounts with no owner
A plain service account often has no named human owner, no inherited policy limits and no built-in expiry, so it tends to accumulate rights over time. Agent accounts tie the automation to a real parent user, which gives a clear accountable owner, but only if that owner is kept current. Confirm which team owns each agent, what happens to its agents when that user leaves, and how revocation is carried out. Assign an accountable owner to every automated identity.
Limits to confirm before rolling out agent accounts
Agent accounts are an Enterprise feature added in authentik 2026.8, and their behavior depends on the exact endpoints, parent user lifecycle and audit fields in your version. The checks below cover what your team must confirm in its own environment before automation depends on them. Treat the release notes as the authoritative reference for each item.
Covered API endpoints and permissions
Confirm which API endpoints an agent account can call, and whether its inherited access matches what the parent user can do in each one. Do not assume that a broad parent role maps cleanly onto a narrow automation task. Test each script or agent against a non-production instance and record every endpoint it reaches, so the scope you approve matches the scope actually used.
Behavior when the parent deactivates
Confirm what happens to an agent account when its parent user is deactivated, locked out or removed. A deactivated parent may stop automation at once, or it may leave tokens working until expiry. Write this down as a tested outcome, because an offboarding runbook that assumes one behavior and gets the other can leave active automation running after a leaver departs.
Supported expiry granularity
Find out how expiry rules can be set, whether by date, by duration or per agent account, and how precisely they are enforced. Check whether expiry renews automatically or needs manual action, and who receives the alert before a credential lapses. Scheduled jobs that fail silently after expiry are a common operational gap, so confirm the failure mode in a test run.
Audit event fields
Confirm which fields each audit event records for agent activity, such as the agent account, the acting parent user, the endpoint, the time and the outcome. Check that events identify the agent as distinct from a human session, because a log that attributes automation to the parent alone weakens investigations. Ask how long events are retained and where they are forwarded.
Fit with your version and upgrade path
Confirm that your chosen authentik version includes agent accounts and that your upgrade plan keeps the feature available. Supported security fix lines are published in the security policy, so check whether your release line is covered before you commit to it. Retest agent accounts after every upgrade, since API behavior can change between releases.
Questions teams ask about authentik agent accounts
Does the open-source edition of authentik include agent accounts?
No. Agent accounts are listed as an Enterprise feature added in authentik 2026.8, so you need an Enterprise license to use them. The open-source code in authentik is under the MIT license, but code in the authentik/enterprise/ directory is covered by a separate enterprise license. The pricing page lists the Open Source edition as free with community support on Discord only. Before you plan around this, confirm the current feature split with authentik directly, since editions and licensing terms can change between releases. Also check the license text in the repository for the enterprise directory, because your legal team will want to review it.
What does the authentik Enterprise license cost for agent accounts?
The authentik pricing page lists Enterprise at $5 per user per month billed annually, plus $0.02 per external user per month. Enterprise Plus starts at $20k annually and adds dedicated support with SLAs, multi-instance deployment support and FIPS compliance for FedRAMP requirements. Agent accounts are part of the Enterprise feature set, so the license is a recurring cost that scales with your user count and external user count. Confirm with authentik which edition includes the agent account controls you need, and ask whether external users are counted in your quote. Any DeployOpen engagement to configure the work is quoted separately from the written scope.
How long does it take to roll out agent accounts in authentik?
The duration depends on how many automations exist, how they authenticate today, and how many policy groups they need. The license and product choice do not set the timeline. Teams usually spend the most time inventorying scripts and AI agents, mapping each one to a parent user, and deciding which inherited policy access is acceptable. Other drivers include expiry rules for each credential, integration testing against the systems that call the authentik API, and whether audit events flow into your existing log platform. No duration is fixed by the product itself, so ask for a phased plan with milestones in the written scope.
What must our internal team provide before an agent account rollout?
Your team needs to supply a clear inventory of scripts, pipelines and agents that call the authentik API, plus the named parent user each one should act for. You also need owners for each automation who can approve expiry periods and review access. Access to a non-production authentik instance, the current deployment details, and a decision on where audit events are stored are also required. Finally, confirm which Enterprise edition your organization has licensed, since this determines which controls are available. Gathering these items early reduces rework during build and testing.
Can our own team set up agent accounts without a partner?
Yes, if your team already runs authentik and has administrators comfortable with its policies, groups and API. Agent accounts are configured inside authentik, so the work is mostly design and administration rather than new infrastructure. The harder part is governance: deciding who owns each automation, how long credentials last, and how audit events are reviewed. Teams without that experience often underestimate testing across each automation. A small internal pilot on one or two non-critical scripts is a reasonable way to find gaps before scaling.
When should we hire a partner for authentik agent accounts?
Consider a partner when many automations and AI agents need to move at once, when access reviews must satisfy an auditor, or when your team lacks spare capacity for design and testing. A partner is also useful when the deployment itself is part of the work, such as Kubernetes, PostgreSQL or upgrade planning. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ask any partner for a written scope that lists each automation, the control design and the test evidence.
What drives the effort of an agent account project?
Effort rises with the number of automations, the variety of their authentication methods, and the size of the policy model. Each service that inherits access from a parent user needs its own review, expiry rule and test case. Integration with your logging pipeline, documentation for auditors, and change control for future upgrades add further work. Effort falls when automations share a standard pattern and when the parent user model is simple. Ask for an effort breakdown by automation group in any quote so you can see which items drive cost.
What recurring work comes after agent accounts go live?
Recurring work includes renewing the Enterprise subscription, reviewing which automations still need access, and rotating or expiring credentials on the schedule you set. You also need to watch audit events, respond when an automation fails, and plan authentik upgrades. The supported versions receiving security fixes are listed in the authentik security policy, and security releases are announced at least 24 hours in advance, so schedule time to apply them. Ask whether support is handled internally or through a retainer, and what is included in each option.
Operating agent accounts after go-live
Once agent accounts are live, the day-two work is keeping each one tied to a current, justified purpose. Start with a scheduled review of every agent account, its parent user, the groups and policies it inherits through that parent, and the applications and API actions it can reach. Because an agent account acts on behalf of a parent user, a change to that user's group membership or policy bindings changes what the agent can do, so review the parent as well as the agent. Record who approved each account and what it is for, and remove any account whose automation no longer exists. Confirm in your own environment how often reviews run and who signs them off, since authentik does not set a review cadence for you.
Credentials need the same discipline. Agent tokens should carry the shortest practical expiry for the job they do, and the expiration rules introduced with agent accounts in authentik 2026.8 are the place to enforce that. Rotate the credential when an agent's code, host or hosting team changes, and revoke it immediately if a script is copied to an unmanaged machine or an AI agent behaves unexpectedly. Keep a short runbook for emergency revocation that names the person allowed to act, and test it once in a non-production instance so the first real use is not the first test.
Monitoring audit events is what turns these controls into evidence. Forward authentik's audit trail to your log platform, alert on API calls from agent accounts outside their normal hours or endpoints, and review failed authentication attempts for agent credentials. For upgrades, stay on the supported 2026.8.x line, which the authentik security policy lists alongside 2026.5.x, and plan around the rule that security releases are announced at least 24 hours in advance, so your window for testing and rollout is short. Read the authentik security policy before setting your on-call process. Retire an agent when its job ends, when its parent user leaves, or when its audit history shows access it no longer needs, and delete the account rather than leaving it dormant.
Choosing between agent accounts, service accounts and token exchange
Before you create a credential for a script or AI agent, decide who the caller acts for, whose policies it should carry, who must appear in the audit trail, and how stable the workload is. Those four answers point to the right identity pattern, and the cards below walk through each one.
Does the caller act for a person?
If the script or agent is doing work on behalf of a specific employee, such as drafting changes in their name or reading data they are allowed to see, an agent account ties the API calls to that parent user. If the work belongs to the platform itself, such as a nightly sync that no one owns personally, a plain service account is usually the cleaner fit. Write the answer down per workload, because mixing the two patterns in one integration makes later reviews hard to follow.
Should it inherit the parent's policies?
An agent account in authentik 2026.8 can inherit the policy access of its parent user, so it sees what that person sees. Check whether that inheritance is what you want, since a parent with broad group membership would pass that breadth to every automation they own. A service account carries only the access you grant it directly, which is easier to reason about but needs its own maintenance.
Must the audit trail name the parent?
Ask whether an auditor or incident responder needs to see which person a machine action traces back to. Agent accounts are designed so that API activity is recorded with the parent relationship, and the enhanced audit logging involved is listed as an Enterprise feature on the pricing page. Confirm with your own logging team which fields reach your SIEM before you rely on them as evidence.
Is the workload fixed or changing?
A fixed system with a stable code path and a small, known set of API calls suits a service account with narrowly granted permissions. An AI agent that chooses its own tools and calls at runtime is harder to bound, so tie it to a parent with limited scope, set an expiry rule, and review its access on a schedule. Test what the agent can reach before you grant it production access.
When token exchange fits better
When a service must call another API with a user's delegated authority without holding that user's original token, OAuth 2.0 token exchange is the pattern to evaluate. It solves a different problem from agent accounts, so do not use it as a substitute for a long-lived automation credential. The token exchange page covers how authentik 2026.8 handles trusted providers and grant settings.
Plan access reviews from day one
Whichever pattern you choose, every automation identity needs an owner, a review cadence and a retirement path when its parent leaves or its project ends. Access reviews with Object Lifecycle Management help you schedule those checks for audits, though that feature is in preview, so confirm its status for your version. Build the review step into the design now rather than adding it after the first audit request.
How DeployOpen scopes and delivers agent account rollouts
DeployOpen delivers agent account rollouts under a fixed scope. Before any work starts, the scope, deliverables and acceptance checks are written down and agreed. For this topic, that document should name which automation scripts and AI agents will receive agent accounts, which parent users they will act on behalf of, which applications and API endpoints they need, and which group or policy bindings the parent already holds. Those bindings are the access an agent will inherit, so they are the first thing to review. A quote follows from that written scope, which is why the inventory of automations and parent users is the most useful input a client can prepare.
Configuration happens inside the client's own authentik deployment, whether that runs on Docker Compose, Kubernetes or another infrastructure the client controls. The work covers the agent account settings, expiration rules, the API management permissions that the agent receives, and the audit event configuration that feeds the client's log store. Because agent accounts are an Enterprise feature in authentik 2026.8, the scope should also confirm the licensing position with the client's own procurement team. DeployOpen tests the behavior directly: an agent should fail once its parent loses access, expire on schedule, and leave audit events that a reviewer can trace back to the parent user. Those tests are run against the client's environment, and the results are recorded with the deliverables.
Documentation is written for the people who review the controls. DeployOpen produces the configuration record, the test results, the operating procedure for issuing and retiring agent accounts, and a mapping of each control to the evidence it produces. That material helps internal auditors and external assessors, but DeployOpen does not issue audit reports, attestations or certifications. Ongoing needs such as authentik version upgrades, reviewing inherited access as teams change, and re-running expiry and audit tests after a release are available as retainers, and the retainer scope should be written as carefully as the initial one.
