Keep agent routing aligned with enterprise identity and access controls.
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.
Organizational routing should not bypass identity governance
An agent that needs to know who should act should not have to hold an administrator directory token, browse the complete workforce directory, infer access from an org chart, share one credential across workloads, ignore project boundaries, or guess when no authorized participant is visible.
Roster provides a governed intermediary. Directory connectors materialize selected organizational records. Roster identities represent human users, AI agents, and service accounts. Credentials carry explicit scopes. Resource rules determine what each actor can see and manage.
Separate the security concerns
Determines who or what is connecting to Roster.
Determines which REST or MCP capabilities the credential can invoke.
Determines whether an identity is an administrator, project owner, or member.
Determines which projects, participants, delegations, and records the identity can access.
Determines who should act within the organizational context the caller is authorized to use.
Dedicated identities for every actor type
Authenticate through configured login providers and operate under their mapped Roster identity.
Represent autonomous agent-owned work, ownership, API keys, and audit attribution.
Represent applications, integrations, scheduled jobs, and workload automation.
Belong to a specific identity, carry explicit scopes, and can be revoked or rotated independently.
Directory-backed without becoming another IAM system
Roster supports organizational data from Microsoft Entra ID, Okta, Google Workspace, Workday, LDAP and Active Directory, and controlled CSV feeds. Directory providers remain the external source of truth.
Roster materializes the selected records and membership relationships required for participant resolution. It does not position itself as an identity provider, HRIS, or complete directory-management platform.
Security controls for agent access
A Resolve-only agent may need only mcp:resolve, mcp:projects:read, mcp:participants:read, and mcp:resolve-requests:read.
The scope permits the tool call, but the acting identity still needs access to the relevant project and participants.
Issue different keys for separate agents, environments, applications, and responsibilities.
Disable or delete retired agent and service identities, then revoke or rotate their keys.
AI clients receive Roster credentials rather than direct Entra, Okta, Google, Workday, or LDAP credentials.
Administrators can configure field-level redaction and retention behavior for Roster’s model and operational records.
Authorization is not participant resolution
An authorization system answers: “May this actor perform this action?” Roster answers: “Which actor should be involved?”
Many production workflows need both — Roster resolves the candidate participant, authorization verifies the candidate may act, and the workflow sends or executes the task. Roster complements — not replaces — your policy engine, IAM system, approval platform, or access-control layer.
Designed for controlled deployment
- Self-hosted deployment
- Customer-managed infrastructure
- Customer-selected model provider
- Scoped API and MCP credentials
- Project-level access
- Model-run observability
- Field-level PII controls
- Full audit capability on Enterprise
- Local licence enforcement