---
id: security.access-control
title: Access Control
summary: Understand workspace and Project access, reviewer assignments, protected artifacts, and credentials granted to evaluation Harnesses.
kind: reference
product_area: security
status: stable
updated: 2026-11-09
canonical: /docs/security/access-control
---

# Access Control

## Definition

Authentication identifies the account. Workspace and Project permissions determine access to work. Reviewer assignments identify expert tasks. Harness secret grants authorize runtime credential use. These controls serve different purposes and should be reviewed separately.

## Fields, states, or lifecycle rules

| Access need | Owning control | What the control establishes |
| --- | --- | --- |
| Sign in to the intended workspace | The organization's configured authentication flow | Account identity and workspace context |
| Assign workspace responsibilities | Admin → Directory → Members | Workspace role assignments; separate from direct Project membership |
| Admit members from approved domains | Admin → Security → Domain Control | Domain restrictions on invitations when enabled |
| Restrict incoming workspace access | Admin → Security → IP Address Control | Enabled, nonempty IP allowlist at authenticated workspace access |
| Work with a Project | Project permissions assigned to users or workspace groups | The actions authorized for the selected Project |
| Complete assigned expert work | Contribution and reviewer assignment | The scoped reviewer work; separate from workspace administration |
| Read files, previews or thumbnails | Artifact authorization | Workspace and Project access plus deletion status |
| Use a credential from a Harness | Project secret access and the Harness grant | Runtime resolution for the identified candidate and execution context |
| Inspect workspace audit events | Audit Log read capability | Authorized workspace event access |

Required capabilities are action-specific. For example, updating Domain Control or IP Address Control requires `users:manage`, while workspace Audit Log access requires `activitylogs:read_all`. Check the assigned capabilities and the owning workflow's approval permissions for the action you intend to perform.

- Project permissions can be assigned to individual users or workspace groups. Check direct grants, group membership, and workspace roles when determining effective access.
- **Admin → Directory → Members** exposes workspace role assignments. **Project Settings → Project Members** exposes individual Project memberships.
- A reviewer being assigned a task is distinct from administering the Project or accessing every Project artifact.
- File, preview, and thumbnail access requires an authenticated request with the appropriate workspace and Project permissions, and a check of the artifact's deletion status.
- Workspace secrets are managed separately from Harness source. Management responses show metadata and masked hints. Runtime credential resolution checks the execution context, expiration, and active grants.
- Personnel infrastructure access is distinct from application permission checks. The security policy requires an authorized business purpose for personnel access to customer content.

### Identity and invitations

Sign-in uses the configured authentication flow for the intended organization. Review the enabled sign-in methods, MFA policy, account lifecycle, and session settings against your identity requirements as part of [Security Review and Assurance](/docs/security/assurance).

In **Admin → Security → Domain Control**, add the approved email domains, enable the invitation restriction, and save it. The control applies to invitations. Review existing Members and their roles separately when changing who should retain access.

### Credentials and the execution boundary

Grant a Harness only the credentials its selected experiment needs. For an experiment that keeps actual production data separate, use test-only identities and endpoints with no access to production records. Keep secret values out of Case content, source files, Run Metadata, and outputs.

The saved Harness, connected endpoints, and granted access determine what tools can retrieve alongside the synthetic Case. Review returned content and captured tool arguments or results as part of the experiment.

Runtime grants are tied to the selected candidate and execution context. A credential for one customer's endpoint is not replaced by a Teammately platform credential when that endpoint rejects it. Configure the matching endpoint and test-only customer credential together.

The [Permissions reference](/docs/reference/permissions) and object-specific guides explain operating access. The [Trust Center](https://teammately.ai/trust) describes the published security controls and their individual scope.

## Related task pages

{% related-card-grid title="Inspect the relevant access" %}
- [Reviewer and Project Access](/docs/governance/reviewer-and-project-access)
- [Permissions Troubleshooting](/docs/troubleshooting/permissions)
- [Harnesses](/docs/assets/harnesses)
- [Synthetic Evaluation](/docs/security/synthetic-evaluation)
- [Network Controls and Isolation](/docs/security/network-isolation)
- [Audit Logs and Activity](/docs/security/audit-activity)
{% /related-card-grid %}