# Access Control
Generated: 2026-11-13T08:01:23.671Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
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 %}
---
id: security.network-isolation
title: Network access and IP restrictions
summary: Use workspace IP restrictions and private connectivity, and distinguish network access from synthetic inputs, execution sandboxes, and processing locations.
kind: reference
product_area: security
status: stable
updated: 2026-11-11
canonical: /docs/security/network-isolation
---
# Network access and IP restrictions
## Definition
Teammately provides workspace IP restrictions and private connectivity for agreed deployment paths. Synthetic inputs, managed execution, network access, and processing location address different requirements.
## Fields, states, or lifecycle rules
| Boundary | What establishes it | What to inspect |
| --- | --- | --- |
| Production records stay outside an experiment | Fictional inputs and materials, permitted generation context, and test-only data sources | Project Agent Brief, facets, samples, tools, credentials, and outputs |
| Candidate execution runs in a managed environment | Trialground's saved Harness and runtime configuration | Candidate identity, dependencies, state handling, and captured activity |
| Workspace access comes from allowed addresses | Enabled IP Address Control with a nonempty allowlist | The addresses seen at the application's authenticated workspace boundary |
| Selected traffic takes a private route | Private connectivity arranged for the agreed ingestion or inference path | Direction, endpoints, network ownership, and the selected service |
| Content is processed in an agreed geography | Hosting, model-deployment type, edge delivery, and integration scope | Each processing step and provider, including model calls |
### Configure workspace IP restrictions
1. Open **Admin → Security → IP Address Control** with permission to manage workspace security.
2. Enter the intended IP addresses or CIDR ranges under **Allowed IPs / CIDRs**. Include the addresses your organization actually uses to reach the application.
3. Enable the restriction and save the configuration. An enabled setting needs a nonempty allowlist to restrict access.
4. Have an authorized administrator confirm access from the intended network and the restriction from outside it, using the normal sign-in and application flow.
This setting governs authenticated workspace application access. Project permissions govern authorized actions, while Harness configuration governs outgoing connections. Access-policy lookup failures and denied addresses are different results; use the reported state when diagnosing access.
### Arrange private ingestion and inference
Open **Admin → Security → Private connectivity**. Private connectivity is available as part of your Teammately deployment, including AWS PrivateLink, Azure Private Link, or equivalent connectivity appropriate for the environment.
Review both directions separately:
- **Your network to Teammately:** private access for sending data, including Fieldloop logs.
- **Teammately to your model endpoint:** private access for model requests and responses.
The setup is arranged for your environment through the contact destination on that page. Identify the endpoints, data categories, direction, DNS and routing requirements, and responsible network owners. Review the route and processing geography for each selected service and integration.
### Keep evaluation data separate
Managed Harnesses can make network requests to their configured services. Use endpoints and credentials whose allowed resources are test-only when the experiment must exclude production records. Keep fictional data in the supporting services as well as the initial Case.
A private model connection protects its transport path. Retrieval permissions and data sources determine which records tools can return; the experiment's inputs, tools, and credential grants define its information boundary. Read [Evaluate Without Uploading Production Cases](/docs/security/synthetic-evaluation) for the complete construction and execution workflow.
## Related task pages
{% related-card-grid title="Configure the relevant boundary" %}
- [Admin Console](/docs/admin-console)
- [Access Control](/docs/security/access-control)
- [Evaluate Without Uploading Production Cases](/docs/security/synthetic-evaluation)
- [Data Handling and AI Processing](/docs/security/data-handling)
{% /related-card-grid %}
---
id: security.audit-activity
title: Activity history
summary: Inspect workspace activity, export filtered audit records, and distinguish those records from approval history, runtime credential events, and captured execution.
kind: reference
product_area: security
status: stable
updated: 2026-11-11
canonical: /docs/security/audit-activity
---
# Activity history
## Definition
The workspace Audit Log records supported application events with their actor and action context. An artifact's history records its own changes and decisions. Trialground records candidate behavior captured by supported instrumentation. Use the surface that owns the question you are investigating.
## Fields, states, or lifecycle rules
| Question | Surface | Scope |
| --- | --- | --- |
| Who performed a recorded workspace action? | Admin → Insights → Audit Log | Events available to the authorized workspace reader |
| Who approved or changed a Policy or other governed artifact? | The artifact's activity or approval history | The particular object and version |
| What did this candidate do? | Benchmark Evaluations → Results and recorded steps | Captured requests, responses, tool activity, and capture status |
| Which credential resolution was allowed or denied? | Runtime credential-access records | The credential service's execution context; separate from universal audit coverage |
### Inspect workspace events
Open **Admin → Insights → Audit Log**. Workspace audit access requires the `activitylogs:read_all` capability, granted separately from sign-in access and expert assignments.
Choose the date range and use the available actor, action, and IP filters. Inspect the action description and its Project or object context. When investigating missing results, check the selected range, filters, access, and the event types recorded by the operation.
### Export a filtered CSV
Use **Download first 1K records** to download the first 1,000 matching records with the selected filters. The export includes timestamp in UTC, user, action type, description, Project ID, and IP where recorded. It is separate from the currently displayed page size.
For a review requiring more than the exported population, narrow the date range and retain the filter and range context with each file. Confirm coverage of the review period rather than treating a 1,000-row file as a complete workspace history. Handle the download as workspace information under your organization's access and retention requirements.
### Interpret the records
Application events, infrastructure logs, approval history, and execution trajectories have distinct collection and retention scopes. The operational Log Analytics retention described in the Trust Center is not an Audit Log retention promise.
Captured execution records show the supported instrumentation and reported capture state. Interpret recorded actions alongside that capture state, and use the artifact's approval history to identify approved Policy versions and reviewer decisions.
The CSV export contains the matching application events described above. Review required event coverage, retention, delivery, storage, and integration needs as part of your security review, including any requirements for continuous delivery, immutable storage, or data-read records.
## Related task pages
{% related-card-grid title="Inspect the owning record" %}
- [Admin Console](/docs/admin-console)
- [Approval History and Reviewer Activity](/docs/governance/approval-history-and-reviewer-activity)
- [Trialground](/docs/concepts/trialground)
- [Security Review and Assurance](/docs/security/assurance)
{% /related-card-grid %}
---
id: security.overview
title: Security and Data
summary: Understand Teammately's security controls, customer-data flows, and the option to evaluate with synthetic Cases without uploading production records.
kind: concept
product_area: security
status: stable
updated: 2026-11-09
canonical: /docs/security
---
# Security and Data
You can develop and evaluate AI in Teammately without uploading your production Cases, customer conversations, or business records. Use synthetic Cases and fictional supporting materials to exercise the behavior your team needs. Configure the candidate's tools and credentials for a separate test environment.
Teammately also supports workflows using customer-supplied content. The data you enter, connect, generate, execute, and submit determines what each workflow processes.
## Decision checkpoint
| Your question | Read | What it explains |
| --- | --- | --- |
| Can we keep actual records outside the experiment? | [Synthetic Evaluation](/docs/security/synthetic-evaluation) | Constructed Cases, test-only environments, and what to inspect |
| What reaches Teammately and model services? | [Data Handling and AI Processing](/docs/security/data-handling) | Inputs, outputs, providers, storage, and geographic scope |
| Who can access our work? | [Access Control](/docs/security/access-control) | Workspace, Project, reviewer, artifact, and credential boundaries |
| How do we restrict network access? | [Network Controls and Isolation](/docs/security/network-isolation) | IP restrictions, private ingestion and inference, and execution boundaries |
| Which actions can we inspect or export? | [Audit Logs and Activity](/docs/security/audit-activity) | Workspace events, filtered CSV export, and artifact-specific history |
| Which security commitments apply? | [Trust Center](https://teammately.ai/trust) | Published controls, assessment status, providers, and agreement requirements |
| What should procurement review? | [Security Review and Assurance](/docs/security/assurance) | Independent assessment status and workflow-specific requirements |
| How can we explain a result later? | [Reproducibility](/docs/governance/reproducibility) | The Cases, criteria, and candidate versions used for assessment |
## Security controls and commitments
| Protection | How it works | Scope |
| --- | --- | --- |
| Customer files and backups | Azure Blob Storage encryption at rest with Microsoft-managed keys; public Blob access disabled | Customer and PostgreSQL backup storage accounts |
| Database storage | Platform-managed encryption for database-cluster disks | Database-cluster storage |
| Workspace and Project access | Server-side permissions, including direct user and workspace-group Project grants | The selected workspace, Project, and action |
| Protected files and previews | Authenticated workspace, Project access, and deletion checks | Access requires an authenticated, authorized request |
| Network access | Workspace IP restrictions and deployment-specific private connectivity | Inbound app access, ingestion, and model inference have distinct controls |
| Runtime credentials | Separate workspace secrets and explicit Harness grants | The selected Harness and its authorized execution context |
| Reviewable activity | Workspace Audit Log, artifact history, and recorded execution activity | Each surface records its own event types and scope |
| Recovery | Backup procedures, storage versioning, and soft deletion | Recovery protection and permanent erasure have different lifecycles |
The [Trust Center](https://teammately.ai/trust) gives the individual control descriptions, assessment methods, and dates. Core hosting location, model-processing geography, and traffic delivery are separate considerations.
Teammately does not use customer workspace data to train shared generative models without express written agreement. Providing a requested AI service can still involve processing and retaining content. Review the selected workflow and provider terms separately.
## Compliance and procurement
Use the Trust Center for Teammately's assessment and audit status, and the applicable agreement for contractual commitments. Each assessment identifies the organization and services it covers. Review the controls and agreement that apply to your intended workflows.
Teammately's security program follows the SOC 2 Security criteria, with controls assessed internally. An independent SOC 2 Type II audit is in progress. [Security Review and Assurance](/docs/security/assurance) explains how to review the assessment status and the scope of your intended workflows.
HIPAA-compliant deployments require a signed Business Associate Agreement and deployment approval before protected health information is submitted. The approved services, workflows, integrations, and data categories define that scope.
Retention, deletion, recovery, and processing requirements should cover the intended workflow, including model-service records, logs, files, and backups. A recovery window is separate from a permanent-erasure timeline.
## Related guides
{% related-card-grid title="Understand your data flow" %}
- [Data Handling and AI Processing](/docs/security/data-handling)
- [Access Control](/docs/security/access-control)
- [Synthetic Evaluation](/docs/security/synthetic-evaluation)
- [Network Controls and Isolation](/docs/security/network-isolation)
- [Audit Logs and Activity](/docs/security/audit-activity)
- [Security Review and Assurance](/docs/security/assurance)
{% /related-card-grid %}
---
id: reference.permissions
title: Permissions
summary: Understand the user-facing permission boundaries for projects, reviewers, settings, and expert UI access.
kind: reference
product_area: reference
status: stable
updated: 2026-11-11
canonical: /docs/reference/permissions
---
# Permissions
## Definition
Permissions describe the user-facing access boundaries that affect projects, reviewer work, settings, Expert UI access, and organization administration. Use this page to decide which access surface to inspect before diagnosing a blocked workflow.
Role labels describe responsibilities. Use the Admin Console and project access guides for the permission requirements of each action.
## Fields, states, or lifecycle rules
- Project access affects cases, standards, coverage, benchmark work, and project settings.
- Project permissions can be assigned to individual users or workspace groups. Inspect direct grants, group membership, and workspace roles when checking effective access.
- Reviewer access affects assigned expert work and reviewer-facing surfaces.
- Workspace administration affects individual members, their workspace role assignments, security controls, API keys, and integrations.
- Inspect workspace role assignments in **Admin → Directory → Members** and individual Project memberships in **Project Settings → Project Members**.
- Use [Access Control](/docs/security/access-control) for artifact and Harness-credential boundaries, and [Data Handling and AI Processing](/docs/security/data-handling) for what each workflow processes. The [Trust Center](https://teammately.ai/trust) and your agreement describe security commitments and their scope.
## Related objects
Permissions should be read with [Admin Console](/docs/admin-console), [Workspaces and projects](/docs/concepts/workspaces-projects), [Permissions troubleshooting](/docs/troubleshooting/permissions), and [Reviewer and Project Access](/docs/governance/reviewer-and-project-access).
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Admin Console](/docs/admin-console)
- [Workspaces and projects](/docs/concepts/workspaces-projects)
- [Permissions troubleshooting](/docs/troubleshooting/permissions)
- [Expert UI](/docs/integrations/reviewer-workspace)
- [Complete your first alignment loop](/docs/quickstart)
{% /related-card-grid %}
---
id: governance.reviewer-project-access
title: Reviewer and Project Access
summary: Route reviewers and project participants to the work they are qualified to inspect or approve.
kind: reference
product_area: governance
status: stable
updated: 2026-11-11
canonical: /docs/governance/reviewer-and-project-access
---
# Reviewer and Project Access
## Definition
Reviewer access combines several explicit boundaries. Organization roles are managed in the Admin Console. Project permissions can be assigned to individual users or workspace groups. Expert Contribution assignment determines which scoped work an expert receives. Artifact approval authority belongs to the owning workflow and must not be inferred from a general role label.
## Fields, states, or lifecycle rules
- A workspace or organization role does not automatically prove access to every Project.
- Check direct Project grants and workspace-group permissions when determining a person's effective access.
- Project membership does not automatically assign a person to every Expert Contribution.
- Assignment makes work available to the intended expert; it does not pre-approve the expert's response.
- Checkpoint and artifact approval state must be read from the Contribution or governed object itself.
- Removing access can prevent future interaction without erasing already recorded responses and decisions.
- API keys, service scopes, and customer integrations are separate authorization boundaries.
- Exact permission keys and enforcement behavior should be read from current administration and project surfaces, not inferred from persona names.
## Related objects
Use [Admin Console](/docs/admin-console) for organization roles and directory controls, [Project Members](/docs/project-settings/project-members) for project participation, and [Expert Contributions](/docs/expert-contributions) for assignment and expert-runtime state. Use the owning Policy, Rubric, Case, or Contribution page to determine approval.
{% example-demo title="Qualified expert without project access" %}
A specialist is the right reviewer for a source-authority Contribution but cannot open the assigned task. The operator checks organization membership, direct and group-based Project access, then Contribution assignment. Granting the missing Project access makes the task reachable; the assignment still controls which work is presented, and the specialist's later Checkpoint decision remains a separate recorded action.
{% /example-demo %}
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Roles and Permissions](/docs/governance/roles-and-permissions)
- [Expert Contributions](/docs/expert-contributions)
- [Permissions](/docs/reference/permissions)
- [Complete your first alignment loop](/docs/quickstart)
- [Choose your starting point](/docs)
{% /related-card-grid %}
---
id: assets.harnesses
title: Manage Harness Drafts and Versions
summary: Build versioned Python Harness bundles, validate and debug Drafts, publish exact Versions, and activate them for benchmark evaluations.
kind: reference
product_area: assets
status: stable
updated: 2026-11-11
canonical: /docs/assets/harnesses
---
# Manage Harness Drafts and Versions
## Definition
A Harness is a project-level, versioned Python bundle used to produce behavior for benchmark cases. It implements `generate_result(request)` at its configured entrypoint and returns the result expected by the case contract. The workspace provides a multi-file editor, one editable Draft, immutable saved Versions, Lemon Code proposals, secret grants, debug runs, runtime preparation, export, and benchmark activation.
A Harness can represent prompt logic, retrieval, tools, orchestration, or other candidate behavior supported by the managed runtime. It is the executable candidate boundary, not a general model registry entry.
## Fields, states, or lifecycle rules
- A newly created Harness begins with one blank editable Draft.
- Draft source and runtime changes autosave after a short delay. A concurrent edit is reported so you can reload the current Draft and review the conflicting change.
- The Draft contains source files, an entrypoint, Python version, dependency specifications, sandbox profile, and target-platform/runtime facts.
- Draft validation errors block publication. Warnings remain visible for operator review.
- **Publish** creates an immutable saved Version from the exact Draft bundle and runtime configuration. Publication also requests use of that Version for the selected Benchmark; confirm its **In use** state.
- A previously saved Version can be selected with **Use this Version** for the current benchmark.
- Existing Runs keep their referenced Harness version even after later Draft or Saved changes.
- Archived Harnesses remain visible but cannot be edited, debugged, activated, or granted new secrets.
- Credentials belong in workspace secrets and are explicitly granted to the Harness. Secret values do not belong in source, case content, or Run Metadata.
- Lemon Code proposals appear as file diffs. Accept or reject the proposed hunks before they modify the canonical Draft.
- Runtime delivery can include the rendered case view, static `case_material_refs`, and an optional supported `world_instance_ref`.
- Debug runs execute only a saved Version against a `harness_contract.v1` request. They are authoring checks, not benchmark evaluation results.
## Draft, saved version, and activation
Use Draft for active editing. Publish when a candidate is coherent enough to identify, compare, or evaluate. If a benchmark needs a different saved Version, select it explicitly. Do not describe a Run as evaluating “the current Harness” because the Draft and benchmark activation may have changed after the Run began.
Use **Publish** or **Use this Version** in the Harness editor to select a saved Version for the current Benchmark. At evaluation launch, choose the saved candidates, machine, and Trials. Each Run retains the Version it executed while your team continues developing the draft.
## Runtime, debug, and output mapping
Publishing preserves bundle and dependency hashes and can prepare the immutable runtime image. A failed or missing runtime can be prepared or retried from the saved Version. Use Debug to send a single contract-shaped request before spending a benchmark Run.
Output mapping is a separate boundary. A Harness return must match the benchmark's declared result contract. For imported candidate responses, Benchmark Evaluations maps uploaded rows to the frozen Cases in the selected Benchmark Version. Inspect the mapped responses and their rubric judgments in Results; Case reference responses remain separate examples of intended behavior.
Lemon Goal Sessions can generate or receive candidate Harness Versions. Those candidates become meaningful in a Session only when their identity and canonical evaluation receipt are observable.
{% example-demo title="Example: exact candidate identity" %}
An engineer edits retrieval filtering in a Harness Draft and publishes Version 12 for the selected benchmark. A managed Run records that exact Version. The engineer then continues editing the Draft toward Version 13. The existing Run still refers to Version 12, so its case responses and rubric results remain attributable even though the editor shows newer work.
{% /example-demo %}
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Run a Benchmark Evaluation](/docs/benchmark-evaluations/run-evaluation)
- [Start a Lemon Goal Session](/docs/improve/start-improvement-session)
- [Project Input Schema](/docs/project-settings/input-schema)
{% /related-card-grid %}