# Network access and IP restrictions

Generated: 2026-11-13T08:01:23.751Z
Source build: local
Canonical docs: https://teammately.ai/docs

<doc id="security.network-isolation" slug="security/network-isolation" url="https://teammately.ai/docs/security/network-isolation.md" title="Network access and IP restrictions" updated="2026-11-11" status="stable">
---
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 %}
</doc>

<doc id="security.overview" slug="security" url="https://teammately.ai/docs/security.md" title="Security and Data" updated="2026-11-09" status="stable">
---
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 %}
</doc>

<doc id="security.synthetic-evaluation" slug="security/synthetic-evaluation" url="https://teammately.ai/docs/security/synthetic-evaluation.md" title="Evaluate Without Uploading Production Cases" updated="2026-11-09" status="stable">
---
id: security.synthetic-evaluation
title: Evaluate Without Uploading Production Cases
summary: Use synthetic Cases, fictional materials, and a test-only Harness environment to evaluate behavior while keeping actual production records outside the experiment.
kind: task
product_area: security
status: stable
updated: 2026-11-09
canonical: /docs/security/synthetic-evaluation
---

# Evaluate Without Uploading Production Cases

Uploading production Cases is optional. You can construct the situations your agent must handle from behavioral requirements, expert judgment, and coverage design, then evaluate them in Trialground. Actual customer conversations, transactions, and confidential documents can remain outside that experiment.

Lemon Weave provides the synthesis capability: it constructs candidate Cases, controlled alternatives, and supporting materials from the context and coverage you supply. Trialground runs saved Harness Versions in managed sandboxes and assesses recorded behavior against your benchmark criteria.

## Prerequisites

- A Project whose Project Agent Brief and coverage definitions contain only information permitted for this experiment.
- A selected Benchmark, its Project Input Schema, and permission to manage coverage and candidate membership.
- A named behavior to examine and the fictional facts or materials needed to examine it.
- A Harness with test-only endpoints and credential grants when actual production data must remain outside execution.

## Inspect the generation context

Describe the task, relevant rules, exceptions, and conditions using information approved for this workflow. Use fictional names, identifiers, documents, and tool results. Match the Project Input Schema and required material formats so the Case has the structure your candidate expects.

If a real incident motivates the Case, describe the behavioral distinction without copying its private records. Generated content can reproduce sensitive facts supplied in instructions or reference material. Review inputs and materials before admitting them to the benchmark.

Generation uses Project context as well as the text you enter for one request. Inspect the **Project Agent Brief**, the selected Dimensions, Topics and Scenarios, their descriptions and source context, and any selected sample Cases. Descriptions derived from an actual incident can contain private details even when no production Case is selected.

The fictional-only boundary applies to this whole input set. A request to use fictional names is a generation instruction; it is separate from excluding sensitive source information before processing.

## Prepare new Cases through Shots

1. Open the intended Benchmark's **Coverage Design → Canvas**, then choose **Shots**.
2. Start a **New Shot** and select the relevant conditions. Choose **Add** and set **Cases to add** to the amount needed for this experiment.
3. Enter the fictional situation and construction requirements in **Additional instructions**. Leave **Sample cases** empty, or retain only samples approved for this workflow. Remove any sample that should not enter generation.
4. Choose **Stage shot**. Inspect the staged request and preview. Use **Update staged shot** if you change it before preparation.
5. Choose **Prepare staged shots** after the preview is ready. This addition path requests newly synthesized candidates. Preparation through **Rules** can reuse existing Case Pool candidates, so source behavior should be read from the operation you actually choose.
6. Inspect the prepared Cases and required materials in the Canvas preview. Review their source relationships and eligibility, select the acceptable candidates, and approve them through the preview's review controls.
7. Confirm the current editable Benchmark membership. Create the intended Snapshot and Benchmark Version before using that fixed population and its criteria for evaluation.

Shots can be configured with sample Cases. Synthesis-only creates new candidates using the Project Agent Brief, selected facet context, and any supplied samples. Review each of these inputs for the experiment's information requirements.

## Keep the execution separate

Configure the Harness to use test-only services, fictional state, and credentials scoped to test resources. Review retrieval sources, environment configuration, callbacks, tool responses, and outputs so the whole experiment follows the intended information boundary.

Trialground manages the execution environment; the Harness defines model calls, tools, and task behavior. A job can process several Cases in one process and workspace. Configure per-Case state and reset behavior when independence is required. The selected endpoints, credential grants, and network configuration define the execution's connectivity.

Use [Network Controls and Isolation](/docs/security/network-isolation) to review workspace access and private ingestion or inference separately from the candidate's data access.

## Choose where execution runs

| Execution choice | What stays separate | What Teammately receives |
| --- | --- | --- |
| Managed Trialground execution with synthetic Cases and test-only tools | Actual production records and systems can remain outside the experiment | Supplied context, Cases, materials, the saved Harness, responses, and captured activity |
| Execution in your own environment with output submission | Your application execution and unsubmitted internal records remain there | Benchmark Cases and criteria already in Teammately, submitted responses or failures, and any included trajectories or telemetry |

External execution keeps the candidate runtime in your environment. Teammately receives the outputs and trajectories you submit for assessment. Review those submissions for the information they contain.

## Review what the assessment establishes

Experts should check realism, valid conditions, expected behavior, and the distinctions each Case exercises. Freeze the intended Case population and criteria in a Benchmark Version, then inspect responses and recorded steps.

Synthetic evaluations assess behavior in the constructed situations. Use representative production observations to understand event frequency, and assess actual integrations and production behavior within the customer's approved environment.

## Object and state changes

Staging a Shot records the proposed request in the current editing session. Preparation records an execution and produces candidates for review. Approval changes the editable Benchmark population through its owning action. Saved Snapshots and historical Runs retain their recorded populations and candidate identities.

## Success criteria

- Generation context, selected samples, and supporting materials meet the experiment's information boundary.
- Prepared additions are newly synthesized, and the accepted Cases demonstrate the intended distinction.
- The selected Harness uses only the endpoints, identities, and resources appropriate for the experiment.
- The resulting Benchmark Version, candidate Version, outputs, and captured activity are identifiable.

## Common failure modes

- Starting a synthesis-only request with sensitive Project Brief or facet content still in scope.
- Leaving an actual customer Case attached as a sample.
- Confusing a Rules preparation that reuses Cases with a new Shot addition.
- Connecting a fictional Case to a production retrieval source or credential.
- Treating preparation completion as approval or assuming execution teardown deletes retained outputs.

{% example-demo title="An invented refund history" %}
A team wants an agent to recognize that a partial refund has already been issued. It defines the rule with an approved fictional policy, creates an invented order with a $120 payment and a prior $40 refund, and supplies a test-only refund service. Variants change the earlier operation's status or repeat its request identifier. Reviewers check the eligible remainder, uncertain completion, and duplicate-action handling without supplying a customer's actual order or payment record.
{% /example-demo %}

## Related workflows

{% related-card-grid title="Construct and assess the experiment" %}
- [Synthesize Cases](/docs/coverage-engineering/synthesize-cases)
- [Review Prepared Cases](/docs/coverage-design/case-review)
- [Harnesses](/docs/assets/harnesses)
- [Run a Benchmark Evaluation](/docs/benchmark-evaluations/run-evaluation)
- [Connect Model Outputs](/docs/integrations/connect-model-outputs)
- [Data Handling and AI Processing](/docs/security/data-handling)
{% /related-card-grid %}

## Related reference pages

{% related-card-grid title="Understand the experiment's boundaries" %}
- [Network Controls and Isolation](/docs/security/network-isolation)
- [Project Agent Brief](/docs/agent-setup/project-context)
- [Project Input Schema](/docs/project-settings/input-schema)
- [Harnesses](/docs/assets/harnesses)
{% /related-card-grid %}

## Related troubleshooting pages

{% related-card-grid title="Investigate an unsuitable candidate" %}
- [Synthetic Cases That Feel Unrealistic](/docs/troubleshooting/unrealistic-synthetic-cases)
- [Unclear Cases](/docs/troubleshooting/unclear-cases)
{% /related-card-grid %}
</doc>

<doc id="security.access-control" slug="security/access-control" url="https://teammately.ai/docs/security/access-control.md" title="Access Control" updated="2026-11-09" status="stable">
---
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 %}
</doc>

<doc id="admin-console.overview" slug="admin-console" url="https://teammately.ai/docs/admin-console.md" title="Administer access and data" updated="2026-11-11" status="stable">
---
id: admin-console.overview
title: Administer access and data
summary: Use Admin in the main app to manage workspace access, integrations, API keys, Lemon instructions, and usage.
kind: reference
product_area: admin_console
status: stable
updated: 2026-11-11
canonical: /docs/admin-console
---

# Administer access and data

Open **Admin** in the main Teammately app for workspace administration. Project Settings manages project-specific configuration; Benchmark workspaces own datasets, Contributions, evaluation and improvement.

## Definition

Admin groups controls into Directory, Security, Insights, Organization Settings and Integrations. Current destinations include Members, Domain Control, IP Address Control, Private connectivity, Audit Log, Usage Statistics, Lemon instructions, Profile, Support Settings, Integrations and API Keys.

## Fields, states, or lifecycle rules

- Workspace membership and project access are separate boundaries.
- Project permissions can be assigned to individual users or workspace groups.
- Project membership and an expert's assigned Contribution are separate.
- Each API operation uses its documented capability and resource scope.
- A connected provider account does not by itself authorize every training or inference operation.
- Recorded usage quantities, processing health and charges have different meanings.

## Choose the owning control

Use Members and the relevant security controls for workspace participation and allowed access. Use Project Settings → Project Members for direct user memberships in one Project. When checking effective access, also consider workspace-group permissions and the person's workspace role.

[Access Control](/docs/security/access-control) maps the current membership, invitation, artifact and Harness-credential boundaries. [Network Controls and Isolation](/docs/security/network-isolation) gives the IP Address Control steps and distinguishes incoming access from private ingestion, model inference and candidate network access.

Use Lemon instructions for workspace-level activity guidance. Project overrides take precedence where configured, and change history is automatic.

Use Integrations for messaging, repository, trace-store and training connections. Each service has its own authorization, configuration and operational result. A successful connection check is different from delivery or a completed provider job.

Use API Keys to create a credential for the intended capability. Current types include Full Access, Read Only and Fieldloop Submission. Copy a newly issued value only into the approved secret mechanism.

## Inspect usage

Usage Statistics shows recorded measurements for the chosen date range and workspace processing state. Quantities are not charges. A processing-status failure does not erase already recorded quantities.

Use the usage guide to connect measurements and ledger entries with the work your team authorized. The [pricing guide](https://teammately.ai/pricing) explains included assistance, metered services, and agreement-defined rates.

For workspace events, open **Admin → Insights → Audit Log**. [Audit Logs and Activity](/docs/security/audit-activity) explains access, filters, the **Download first 1K records** CSV operation, and the difference between workspace events, artifact history and captured execution.

## Private connectivity

Private connectivity is available as part of your Teammately deployment. In the main Teammately app, open **Admin → Security → Private connectivity** to learn about AWS PrivateLink, Azure Private Link, or equivalent connectivity for your environment.

Private networking can cover:

- **Your network to Teammately:** private access for sending data, including Fieldloop logs, to Teammately.
- **Teammately to your model endpoint:** private access for model requests and responses.

Private connectivity is arranged as part of your overall Teammately setup. [Ask us](https://teammately.ai/contact) about your deployment.

## Access and authority

Read each permission from its owning surface. A role name used in an orientation page describes responsibility; it is not an exhaustive permission matrix. Approval authority over Policies, Rubrics or Contribution decisions remains with the corresponding workflow.
## Choose your next task

| Guide | What you can accomplish |
| --- | --- |
| [Workspace administration](/docs/governance/workspace-administration) | Administer workspace and project boundaries so correctness work has clear ownership and scope. |
| [Members, groups, and roles](/docs/governance/roles-and-permissions) | Use roles and permissions to route ownership, review, and approval work clearly. |
| [Project access](/docs/project-settings/project-members) | Manage direct Project memberships and understand group-based access while keeping task assignment and artifact governance separate. |
| [Data handling](/docs/security/data-handling) | Trace what enters Teammately, what AI services process, and how workflow choices affect storage, processing locations, retention, and deletion. |
| [Network access and IP restrictions](/docs/security/network-isolation) | Use workspace IP restrictions and private connectivity, and distinguish network access from synthetic inputs, execution sandboxes, and processing locations. |
| [Activity history](/docs/security/audit-activity) | Inspect workspace activity, export filtered audit records, and distinguish those records from approval history, runtime credential events, and captured execution. |
| [Security assurances](/docs/security/assurance) | Review Teammately's current assessment status and define the identity, processing, retention, recovery, and regulatory requirements of your intended workflows. |
| [Reviewer and Project Access](/docs/governance/reviewer-and-project-access) | Route reviewers and project participants to the work they are qualified to inspect or approve. |
| [Permissions](/docs/reference/permissions) | Understand the user-facing permission boundaries for projects, reviewers, settings, and expert UI access. |
| [User roles](/docs/getting-oriented/user-roles) | Understand the responsibilities of project operators, domain experts, AI engineers, accountable owners, and organization administrators. |

## Related task pages

{% related-card-grid title="Related task pages" %}
- [API Keys and Delegated Access](/docs/admin-console/api-keys)
- [Workspace Integrations](/docs/admin-console/integrations)
- [Usage Statistics](/docs/admin-console/usage)
- [Project Members](/docs/project-settings/project-members)
- [Lemon Instructions](/docs/project-settings/lemon-instructions)
{% /related-card-grid %}
</doc>