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
- Open Admin → Security → IP Address Control with permission to manage workspace security.
- Enter the intended IP addresses or CIDR ranges under Allowed IPs / CIDRs. Include the addresses your organization actually uses to reach the application.
- Enable the restriction and save the configuration. An enabled setting needs a nonempty allowlist to restrict access.
- 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 for the complete construction and execution workflow.