---
title: "Identity & Access"
source: "https://docs.vertesiahq.com/agent-runner/identity"
markdown: "https://docs.vertesiahq.com/llms/agent-runner/identity.md"
---

# Identity & Access

Every agent run executes under its own identity. Vertesia does not hand an agent a user's session token or run agents under a shared service account. Instead, each run gets a dedicated, scoped, short-lived credential, and every action the agent takes is authorized and audited against it.

## A per-run agent identity

When an agent starts, Vertesia's security token service mints a dedicated token for that run:

- **Its own principal.** The token identifies an `agent` principal with a unique, per-run subject — not the launching user, and not a shared account.
- **Scoped to one project.** The token is bound to a single account and project, verified at mint time. An agent cannot reach across projects it was not launched in.
- **Short-lived.** The token is time-bound. Long-running agents (see [Workstreams](/agent-runner/workstreams) and [Workflows](/workflows/overview)) re-mint fresh credentials as they run rather than holding a single long-lived token.

## Acting on behalf of the launching user

An agent acts **on behalf of** the user (or workload) that launched it. The per-run token carries that user's verified identity — their roles, group memberships, application access, and content-security rules — and every permission check and every content query resolves against it.

Two consequences follow, and both matter for enterprise use:

- **An agent can do what its launcher can do — and never more.** Authority is bounded by the launching identity. An agent launched by a user with read-only access to a collection cannot write to it, regardless of what the model decides to attempt.
- **The launching identity is verified, not asserted.** The on-behalf-of identity is checked (signature and account) when the agent token is minted, so an agent cannot escalate by claiming an authority it was not given.

## Authorization is enforced everywhere the agent acts

The same identity is enforced consistently across the platform — not only at the API boundary:

- **Tool calls** are authorized against the agent's effective identity before they run.
- **Content access** is filtered by the launching user's permissions and content-security (attribute-based) rules. An agent's search and retrieval return only what that identity is allowed to see.
- **Application and tool-surface access** is gated by the apps the launching identity is entitled to.

## Auditing

Actions are attributed to both the agent principal and the identity it acted for. The audit trail records *which agent* performed an action and *on whose authority* it ran, so an agent's activity is never anonymous and never detached from an accountable human or workload.

## Scoping an agent

Beyond the inherited user permissions, an agent run can be narrowed further:

- **Project and account** — bound at mint time.
- **Collection** — an agent can be restricted to a specific content collection, limiting both what it can read and where it can write.
- **Application access** — the tool surfaces and integrations an agent can reach follow the launching identity's app entitlements.
- **Content security** — read, write, and delete are governed by the same attribute-based rules that apply to users, applied as a query filter at access time.

## Scheduled and headless runs

Agents launched on a schedule run on behalf of the identity that created the schedule, captured when the schedule is defined. Agents invoked through the SDK or API run on behalf of the calling identity. In both cases the same rule holds: the agent is bounded by, and audited against, the identity it runs for.