# Security assurances
Generated: 2026-11-13T08:01:25.937Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: security.assurance
title: Security assurances
summary: Review Teammately's current assessment status and define the identity, processing, retention, recovery, and regulatory requirements of your intended workflows.
kind: reference
product_area: security
status: stable
updated: 2026-11-11
canonical: /docs/security/assurance
---
# Security assurances
## Definition
A security review connects your intended use with the applicable technical controls, operating responsibilities, provider terms, and agreements. Identify the workflows and information involved before treating a general security statement as a commitment for every operation.
## Fields, states, or lifecycle rules
### Assessment status
Teammately's security program follows the SOC 2 Security criteria, with controls assessed internally. An independent SOC 2 Type II audit is in progress. The [Trust Center](https://teammately.ai/trust) publishes the current status and gives the method and date for individual control descriptions.
Internal control review, adopted security policies, and a completed independent assessment are different forms of assurance. When reviewing a report, check the legal entity, included services, assessment period, exclusions, and customer responsibilities. Hosting and model-provider reports describe the provider controls within their stated scope; Teammately's assessment covers its own included services and workflows.
### Define the intended use
| Review topic | Establish for the selected workflows |
| --- | --- |
| Information submitted | Cases, Project instructions, Reference Materials, expert content, files, outputs, and recorded activity; whether production records are excluded |
| Identity | Required sign-in or SSO method, MFA enforcement, account provisioning and removal, and session requirements for the agreed identity setup |
| Authorization | Workspace roles, direct and group Project grants, reviewer assignments, artifact access, API credentials, and Harness grants |
| Network | Inbound IP restrictions, private ingestion, private model inference, endpoints, and network owners |
| Processing location | Core hosting, the selected model deployment, traffic delivery, and connected service locations |
| Provider processing | Data sent to each service, requested model features, stateful storage, and the applicable processing and training terms |
| Audit | Required event types, authorized readers, review periods, export needs, and retention scope |
| Retention and deletion | Active records, files, recordings, model-service state, logs, backups, and the treatment of deleted content after restoration |
| Recovery | Required recovery point and recovery time, backup scope, restoration responsibilities, and the workflows the commitment covers |
| Personnel and support | Authorized business purposes for content access and the responsibilities of your administrators and participating experts |
Review the sign-in methods, MFA policy, provisioning integrations, and session settings configured for your deployment against your organization's identity requirements. Domain restrictions govern which email domains are permitted for invitations.
### Regulated information
HIPAA-compliant deployments are available under a signed Business Associate Agreement and deployment approval. Complete both before submitting protected health information. The agreement identifies the approved services, workflows, data categories, integrations, providers, and responsibilities. PHI processing follows this approved deployment and agreement scope.
The Privacy Policy describes website, account, and business-administration processing. Customer workspace content is processed on the customer's instructions. The purpose and applicable agreement determine the processing role.
### Prepare a review request
Use the [Trust Center](https://teammately.ai/trust) contact destination to share your required workflows and controls. Include the categories of information and required locations, access, audit, retention, and recovery terms. Keep actual customer records, credentials, and regulated information out of the initial inquiry.
Record the agreed scope with your organization. Technical settings, contractual requirements, and independent assessment status should remain identifiable separately as the use changes.
## Related task pages
{% related-card-grid title="Review the relevant controls" %}
- [Data Handling and AI Processing](/docs/security/data-handling)
- [Access Control](/docs/security/access-control)
- [Network Controls and Isolation](/docs/security/network-isolation)
- [Audit Logs and Activity](/docs/security/audit-activity)
- [Evaluate Without Uploading Production Cases](/docs/security/synthetic-evaluation)
{% /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: security.data-handling
title: Data handling
summary: Trace what enters Teammately, what AI services process, and how workflow choices affect storage, processing locations, retention, and deletion.
kind: reference
product_area: security
status: stable
updated: 2026-11-11
canonical: /docs/security/data-handling
---
# Data handling
## Definition
Customer content includes more than uploaded Cases. Project instructions, Reference Materials, expert contributions, files, candidate responses, and captured tool activity can all contain business information. Synthetic experiments process and retain the selected context, constructed inputs, and resulting activity according to the chosen workflow.
## Fields, states, or lifecycle rules
| Workflow | Information processed | What to review |
| --- | --- | --- |
| Project setup and expert work | Entered instructions, materials, comments, answers, and supported recordings | Which information participants supply and who can access it |
| Case synthesis | Coverage requirements, supplied context, generation instructions, and generated Cases or materials | Whether every source is suitable for the intended processing |
| Managed Trialground execution | Selected Case inputs, materials, saved Harness, outputs, and captured trajectory events | Tools, granted credentials, model calls, returned data, and retained records |
| External execution and output submission | Benchmark Cases and criteria held in Teammately, plus submitted responses, failures, and any included trajectories | What remains in your environment and what the submission transmits |
| Connected integrations | Data selected for the specific connection and operation | Provider, access scope, processing location, and applicable terms |
### Follow the information through the workflow
For a synthetic experiment, permitted Project context and fictional requirements feed Case and material generation. The selected Cases, materials and saved Harness then enter managed execution, or your own execution environment. Submitted responses and captured activity enter assessment and the resulting Run records.
| Information | Where it enters or remains | Selection and access responsibility |
| --- | --- | --- |
| Project Agent Brief and coverage definitions | Context for construction and other selected AI workflows | Review the Brief and relevant Dimensions, Topics, Scenarios, and source descriptions |
| Sample Cases and source material | Generation context when the selected operation includes them | Remove unapproved samples before preparation; new synthesis and source exclusion are different choices |
| Inputs, generated materials and candidate code | Benchmark assets and the selected execution | Project permissions and candidate selection govern use |
| Tool requests and returned content | The Harness's configured services and supported captured activity | Endpoints, resource permissions, credential grants, and capture configuration |
| Responses and recorded execution | Run, Results, and supported execution records | Review content before external submission and apply the intended access scope |
| AI-service state | The model feature requested by the owning workflow | Provider terms, feature configuration, processing location, and retention scope |
Private ingestion and inference provide private transport for agreed paths. Review the submitted information and each service's processing location alongside that network configuration. See [Network Controls and Isolation](/docs/security/network-isolation).
### Core services and processing locations
The [Trust Center](https://teammately.ai/trust) lists Microsoft Azure for application hosting, databases, storage, backups, and AI processing; Auth0 for authentication; and Cloudflare for proxied traffic and delivery. Core Azure hosting is in Central US. Model services and traffic delivery have their own processing geographies, described below and in the Trust Center.
Teammately's platform AI processing uses Azure OpenAI or Microsoft Foundry. Global model deployments may process prompts and responses across supported geographies. Customer-selected Harness endpoints and integrations have their own processing scope.
### Model training and service storage
Teammately does not use customer workspace data to train shared generative models without the customer's express written agreement. This commitment is separate from processing content for a requested service or retaining operational records. Customer-requested weights training is a separate workflow with its own selected dataset and provider.
Model-service storage follows the selected API feature and workflow. Managed execution retains outputs and captured trajectory events outside the sandbox, where they remain available after execution ends under the applicable retention arrangements. Review [Microsoft's AI data-processing terms](https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy) alongside the features and integrations you select.
### Retention, deletion, and recovery
Your requirements should distinguish active application records, files, model-service data, logs, and backups. The applicable agreement and selected workflows determine the retention and deletion commitments. Storage soft deletion and backup recovery periods describe recovery protection. Permanent-erasure timelines apply to the agreed records and stores in the deletion scope.
The [Privacy Policy](https://teammately.ai/privacy) and Trust Center describe privacy-request handling. Customer-controlled workspace content is handled on the customer's documented instructions, with identity and authority checks where appropriate.
| Record category | Retention or deletion scope to establish |
| --- | --- |
| Active Project and Benchmark records | The selected objects, permitted use, historical versions, and applicable agreement |
| Files, generated artifacts and supported recordings | Originals, derivatives, versions, and references held by the workflow |
| Model-service records | Uploaded content and stored state requested by the selected feature |
| Application and audit logs | The relevant event collection and its retention; infrastructure-log retention is separate |
| Backups and recovery copies | Recovery windows, expiration, and the handling of previously deleted content after restoration |
Use the privacy-request process to identify the authorized objects and stores in a deletion request. Record the agreed completion criteria and treatment of historical or recovery copies. Review active records, retained execution data, and recovery copies as distinct parts of that scope.
### Recovery objectives
Teammately's published controls describe database backup and restoration procedures, storage versioning, and soft-deletion protections. Review those protections alongside the required recovery point and recovery time, then define the applicable objectives for the agreed deployment and workflows.
## Related task pages
{% related-card-grid title="Choose the intended data flow" %}
- [Synthetic Evaluation](/docs/security/synthetic-evaluation)
- [Synthesize Cases](/docs/coverage-engineering/synthesize-cases)
- [Connect Model Outputs](/docs/integrations/connect-model-outputs)
- [Run a Benchmark Evaluation](/docs/benchmark-evaluations/run-evaluation)
{% /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 %}