Agent routing that respects your identity boundary.

Give agents and workflows access to current organizational context without handing them unrestricted directory credentials or embedding identity logic in every application.

Roster separates participant resolution from authentication, authorization, source directories, and workflow execution — so security controls stay where they belong.

Review Roster securityExplore authorization

Every resolve call flows through five governed layers

An agent asking “who should act?” never touches the directory directly. The request passes five independent checks before Roster returns a participant — each one owned by a different security concern, each one auditable on its own.

Caller
AI agent · workflow · CI job
01
authn
Authentication
Who or what is connecting to Roster? Human via SSO, agent via API key, service account via scoped credential.
02
scope
Credential scope
Which REST or MCP capabilities may this credential invoke? mcp:resolve, participants:read, and nothing else.
03
role
Platform role
Is this identity an administrator, project owner, or member? Roles gate configuration and cross-project reach.
04
resource
Resource authorization
Which projects, participants, delegations, and records is this identity allowed to reach at all?
05
resolve
Participant resolution
Given all of the above, which user, group, role, or delegate should be involved in the workflow now?
Resolved
Governed participant
// effective access = credential scope ∩ owner rights ∩ resource rules

One identity model for humans, agents, and workloads

Every actor gets its own Roster identity — with distinct authentication, distinct credentials, distinct lifecycle, and distinct audit attribution. No shared keys, no ambiguous callers.

01
identity.human
Human team members

Authenticate through your configured login providers and operate under their mapped Roster identity — with full audit trail tied to the corporate SSO subject.

02
identity.agent
AI agents

First-class identities for autonomous agents, with dedicated API keys, ownership metadata, and per-agent scopes so a compromised agent never impersonates a human.

03
identity.service
Service accounts

For applications, integrations, scheduled jobs, and workload automation — long-lived where needed, revocable at any moment, never confused with a person.

04
identity.key
API keys

Belong to exactly one identity, carry explicit scopes, rotate independently, and are revocable without disturbing the identity or its history.

connectors, not custody

Directory-backed. Not another IAM system.

Roster reads organizational data from the directories you already run. Providers stay the source of truth. Roster materializes only the records and membership relationships needed for resolution — never the whole workforce, never for every agent.

Microsoft Entra IDOktaGoogle WorkspaceWorkdayLDAPActive DirectoryCSV
roster materializes

The participant-resolution layer that sits between your directories and your agents — governed, scoped, auditable. Never an identity provider. Never an HRIS. Never a shortcut around IAM.

Credentials with surgical scope, not blanket access

A Resolve-only agent needs four scopes, not thirty. Every API key is issued to a specific identity, carries an explicit capability list, and can be revoked or rotated without touching the rest of the platform.

API key
roster_agent_prod_a7f9…
identityagent.procurement-bot
Permitted scopes
mcp:resolve
mcp:projects:read
mcp:participants:read
mcp:resolve-requests:read
Denied by scope
mcp:team-members:write
mcp:api-keys:write
mcp:provider-connectors:write
mcp:platform-settings:write
mcp:audit-events:read

Scope permits the call. The acting identity still needs access to the underlying project, participants, and records. Even an over-permissive key can only reach what its identity is authorized to see.

Authorization is not resolution — and vice versa

Policy engines answer whether a known actor may perform a known action. Roster answers who the actor should even be. Both belong in a production workflow. Neither replaces the other.

authorization
Your policy engine
Q. May this actor perform this action?

OPA, OpenFGA, Cedar, or your IAM system evaluates permissions on already-known subjects. Roster hands them a governed candidate to evaluate.

resolution
Roster
Q. Which actor should be involved?

For any workflow context, Roster returns the user, group, role, or delegate that current organizational state points to — then your authorization layer takes it from there.

Roster resolves the candidate. Authorization verifies the candidate may act. The workflow engine executes. Three separable concerns, three separable audit trails, one accountable outcome.

Security controls built into the resolution path

Every control below is enforced server-side, at the moment of resolution — not left to prompt engineering, agent code, or workflow authors.

01
Narrow scopes

Issue credentials with only the capabilities the workload needs. A Resolve-only agent never gains write, admin, or configuration reach.

02
Project boundaries

The scope permits the tool call, but the acting identity must still have access to the relevant project and participants.

03
Separate credentials

Distinct keys for distinct agents, environments, applications, and responsibilities — revoke one without disturbing the rest.

04
Lifecycle management

Disable or delete retired agent and service identities, then revoke or rotate their keys — with the audit trail preserved.

05
Provider separation

AI clients receive Roster credentials, not direct Entra, Okta, Google, Workday, or LDAP tokens. Upstream credentials never leave the connector.

06
PII controls

Configure field-level redaction and retention behavior for Roster's model and operational records, per project or globally.

07
Audit & telemetry export

Durable Audit Events plus opt-in OTLP telemetry export send traces, metrics, and logs to your SIEM and observability stack — never to Advantys. Retention windows are configured per record class.

Frequently asked questions

No. The client authenticates to Roster with a Roster-issued credential. Directory-provider credentials remain server-side connector configuration and never leave the platform.

Govern the organizational context your agents can use

Give agents and automations a controlled path to participant resolution — without bypassing enterprise identity practices.

Review Roster securityExplore authorizationExplore all solutions