Divide agent ownership and access

An agent is the unit your organization gives to one team: its own identifier, its own tokens, its own tools, and its own records. Some boundaries stop at the agent. Others stop at the tenant.

Limits and timings here were checked against the shipped platform on 2026-08-30. They are current behavior, not a commitment.

Every task runs under one agent. Concepts owns the task and result contract, Authoring tools owns the contract for tools you write, and Ownership and approvals owns who decides a routing change.

Give each project its own agent

Your organization chooses each agent identifier: 3 to 50 characters, starting with a letter, then letters, digits, hyphens, and underscores. Give each team a prefix, such as payments-invoice-review, so one access policy can cover that team and no other.

One agent carries one set of these:

The second team runs its own process under its own agent, so your platform team deploys none of its code. You create the agent and hand over two strings, the identifier and one API token. Three things stay central: the model pool, the provider credentials, and the authority to create and revoke agents. Authoring tools covers the team side of that line, and Agent harness covers the platform side.

Two credentials do two different jobs

The credential that changes an agent and the credential that runs it are not the same credential.

By default an agent API token submits tasks, opens a document upload, and creates a Library. It does not create another agent, author a policy, read your model-provider configuration, or change your model pool, and it reaches no Library it did not create. It acts only inside its own tenant. An administrator can widen it through group membership, so review that as you would a person’s role.

One exception. Creating a Library grants the creating agent administrative access to it. A rule it writes there names a subject pattern, so one rule can reach everyone in your tenant. A rule can also refuse access, and a refusal beats an allow, including one an administrator holds. That reach covers only Libraries the agent created, and makes Library creation an access-control capability, not a storage one.

One agent cannot read another agent’s task events

A task identifier belonging to another agent returns no events. Your process reads only the events of tasks your own agent submitted.

No configuration change can turn this off. Concepts states the same rule for request bodies.

The lifecycle of one agent

An agent moves through four steps, then stays until you change or remove it:

1. Create. A member of your tenant creates the agent under an identifier your organization chose.
2. Issue a token. The platform shows it once. Its lifetime is 1 to 365 days and defaults to 90.
3. Serve tools. Your process publishes the agent’s tool manifest and holds it with a heartbeat.
4. Rotate. Issue a replacement token, then revoke the previous one. Revoking one token leaves the agent’s others live.

Renaming changes the display name and the description, never the identifier.

Each token records who created it, when it was created, when it expires, when it was last used, and when it was revoked. The last-used stamp is what makes a dormant credential findable once a tenant holds tens of agents. It is refreshed at most once every five minutes per token, so treat it as accurate to within that interval.

A tool host that stops its heartbeat leaves tool routing four minutes after its last beat. Restart the process to publish the manifest again. Neither needs anyone in your tenant to act.

Delete is not revocation. Deleting an agent stops it and its tokens from working, but does not revoke those tokens, and an administrator can recover it. Recovery makes every unexpired, unrevoked token work again, and access rules written for that identifier still name it. Revoke each token first.

Revoking a token takes effect on the next task request. It stops new requests, not running work: a task already submitted continues, and can run for days.

A revoked token can still be accepted on Library calls for a few seconds. Treat revocation as immediate for tasks and as a few seconds behind for Library calls.

Changing a permission is slower. Removing a Library rule, editing a policy, or changing a group takes up to a minute to take effect. Verify it by the call that must now be refused.

Who can perform each step

Every tenant has three built-in roles that you assign to a person. Nobody in your tenant can change or delete them.

• Viewer reads the agent directory and lists an agent’s tokens.
• Editor does everything a viewer does, and creates an agent, issues its tokens, and revokes its tokens.
• Administrator does everything an editor does, and renames an agent, deletes an agent, and authors an access policy or a group.

Two further built-in policies apply on their own and are not assignable. Every agent gets the default above. Every member of your tenant can read the agent, member, and group directory, whatever role they hold.

The audit log does not follow that order. The bullets above build up, each role doing everything the one before it does. Audit access does not:

Assign audit access from that table, not from the seniority the three names suggest.

An editor can therefore create a project’s agent and its tokens without an administrator. That permission is not limited to one team. It covers every agent in the tenant, so an editor can also create an agent for another team and revoke the tokens that team runs on.

Delegate one team without a tenant-wide role

An access policy adds permission; it never removes one. Scope one to a trailing-wildcard pattern, such as every agent whose identifier starts with a team prefix, and give that team no built-in role. If the team also holds a built-in role, that role reaches every agent and the narrower pattern changes nothing. This documentation does not yet show how to create that policy. Confirm the procedure with Duale AI before you plan a rollout around it.

Plan for the boundaries that stop at the tenant

An agent bounds identity, credentials, tools, task events, and its own task history. It does not bound everything.

What an agent bounds and what the tenant boundsA tenant holds the model pool, the provider credentials, the configuration permissions, and the cost view shown in the web interface. Each agent inside that tenant holds its own identifier, its own API tokens, its own tool manifest, and its own task events. A change at the tenant level reaches every agent inside it.

Three consequences follow:

• Revoke the agent of one team without touching another team.
• Changing an enabled route changes behavior for every agent in that tenant.
• Per-team separation of routes, provider credentials, or the cost view needs separate tenants.

Creating an agent past 100 in one tenant fails. The limit applies at creation, so it arrives as an error on that call, never as a degraded agent later.

The tenant is the unit you add as you grow. It carries its own model pool, its own stored provider credentials, and its own cost view, though not a separate account at the model provider. Add the next tenant when a team needs one of those, or before it reaches the limit. Plan the deployment states what a tenant separates and what it does not, and Architecture patterns compares the shapes.

Because the model pool follows the tenant and not the agent, one enabled route reaches every other agent in that tenant. Treat each model-pool change as a production change for all of them, as Model routing requires.