Skip to main content

Protect coding-assistant traffic

Coding assistants are now a routine part of how software is written, and almost all of them reach a model through the same OpenAI-compatible interface that any other application uses. That convenience is also the risk. When a developer works inside Cursor, Continue, Cline, or a similar assistant, the prompts sent to the model are not casual questions; they are spans of the organisation's own source code, the surrounding files an assistant pulls in for context, configuration that frequently contains credentials, and whatever customer data happens to sit in the buffer being edited. Each of those requests is an opportunity for proprietary source, secrets, or regulated data to leave the organisation through a model call, or to be retained by a provider in a way the organisation never intended.

Tetrate Agent Router sits in the path of those requests, which makes it the right place to treat coding-assistant traffic as its own class and hold it to a stricter standard than general application traffic. This guide covers that work end-to-end: why coding assistants are a distinct risk, how the platform distinguishes their traffic from everything else, how a stricter policy bundle, comprising intellectual property (IP) and secret detection, tighter logging, and an audit trail, is attached to that traffic, and how the result is verified by sending a sample request that carries a seeded secret and confirming the gateway blocks or redacts it. Because the developers who configure these assistants control how that traffic is labelled, a short section covers coordinating with them so the distinction actually holds in practice.

Persona: Platform operator working in the Admin Dashboard, in coordination with the security or compliance owner of the underlying policy and the developers who configure the assistants.

Estimated time: 30--60 minutes, including the verification step and the conversation with the development team that the labelling depends on.

When this guide applies​

This guide is the right starting point in any of these situations:

SituationWhat it covers
Coding assistants are in use and source code or secrets may be flowing through model callsDistinguishing assistant traffic and attaching a stricter policy bundle to it
A policy requires that proprietary code never reach an external model unredactedIP and secret detection applied to the assistant's traffic with a redact or block action
An audit trail is required specifically for AI traffic originating in developer toolingTighter logging and an audit trail scoped to assistant traffic
The stricter controls need to be demonstrated before the evaluation is signed offVerifying with a seeded-secret sample request

For the general mechanics of detecting and redacting sensitive content (the rule types and match actions that this guide reuses) see Detect and redact sensitive data and Configure custom guardrails for PII and content. For how the assistants themselves are pointed at the gateway in the first place, see Integrate the gateway with an app.

Outcomes​

By the end of this guide:

  • Traffic originating from coding assistants can be distinguished from general application traffic at the gateway.
  • A stricter policy bundle (IP and secret detection with a redact or block action, tighter logging, and an audit trail) is attached to that traffic.
  • A sample request carrying a seeded secret has been sent through an assistant's path and confirmed to be blocked or redacted.
  • The development team understands how its assistant configuration determines whether the stricter controls apply.

Prerequisites​

  • Administrator access to the Admin Dashboard, typically the super_admin role or a role granted guardrail- and key-management permissions.
  • A written statement of the policy the stricter bundle is meant to enforce: which categories of content must not leave the organisation through an assistant, and whether a match should be redacted or block the request outright.
  • An inventory of which coding assistants are in use (Cursor, Continue, Cline, and similar) and who configures them. The distinction this guide relies on cannot be enforced for an assistant nobody knows is running.
  • A non-production secret to seed for the verification step. A real credential must never be used as test content; a clearly fake but realistically shaped token serves the purpose without putting anything at risk.
  • Familiarity with custom guardrails, covered in Configure custom guardrails for PII and content.

Step 1: understand why coding-assistant traffic is a distinct risk​

A general application sends a model the content it was designed to send, and that content has usually been through some deliberate handling before it leaves the codebase. A coding assistant is different in three ways that together justify treating its traffic separately.

  • The payload is proprietary source by default. The assistant's purpose is to reason about the code being written, so source (often including files the developer did not consciously decide to share) is the normal content of every request, not an exception.
  • Secrets travel with the code. Configuration files, environment definitions, and inline constants frequently contain API keys, tokens, and connection strings. An assistant that reads the surrounding files for context reads those too, and forwards them to the model unless something stops it.
  • Customer data is often in the buffer. Test fixtures, sample records, and data pasted in while debugging routinely contain real or realistic customer information that the developer is not thinking of as an outbound disclosure.

None of this is malicious; it is the ordinary behaviour of a useful tool. The point is that the volume and sensitivity of what flows through an assistant is high enough, and unconsidered enough, that the controls applied to general traffic are not sufficient. The remainder of this guide raises the floor for this one class of traffic.

Step 2: distinguish coding-assistant traffic​

A stricter policy can only be attached to assistant traffic once that traffic can be told apart from everything else. The platform offers three ways to draw the distinction, in roughly increasing order of how much developer cooperation each requires.

MethodHow the distinction is drawnTrade-off
Dedicated API keyEach coding-assistant integration is issued its own API key, and the stricter bundle is scoped to that keyThe cleanest signal; depends on developers using the issued key rather than a shared one
Request attributes or headersA request attribute or header set by the assistant's configuration marks the traffic as assistant-originatedFlexible, but only as reliable as the configuration that sets it
Routing pathAssistant traffic is sent through a dedicated routing policy or path, distinct from general application trafficKeeps the distinction in the platform rather than the client, at the cost of a separate path to maintain

The dedicated-key approach is the most robust and the one to prefer where it is practical, because it ties the distinction to a credential the platform already issues, tracks, and can revoke. The same pattern of one key per integration is recommended for observability in Integrate the gateway with an app, so coding assistants frequently already have their own keys for that reason; this guide reuses that boundary for policy.

Whichever method is chosen, it is only as good as the configuration on the developer side. Step 6 covers the coordination that keeps the distinction honest.

Step 3: assemble the stricter policy bundle​

The "bundle" is the set of controls applied together to the distinguished traffic. It is built from the same guardrail mechanism used elsewhere in the platform, scoped to the assistant traffic identified in Step 2, with the action set tighter than it would be for general traffic.

  • IP and secret detection. Add guardrails that detect the categories the policy names: secrets such as API keys, tokens, and connection strings; and the markers of proprietary source, such as internal codenames, licence headers, or repository identifiers that must not leave the organisation. A keyword rule covers a closed set of known terms; a regular-expression rule covers structured secrets that follow a predictable shape; a machine-learning-classification rule covers categories too varied to enumerate. The rule types and how to choose between them are covered in Configure custom guardrails for PII and content.
  • Redact or block. For an assistant, redaction lets the interaction continue with the sensitive span removed, useful where stripping a single secret should not derail an otherwise legitimate request. A block stops the request entirely and is the right action where a match means the content should never have been sent at all. The policy statement from the prerequisites decides which applies to each category; many bundles redact incidental secrets and block on the categories that admit no exception.
  • Tighter logging. Apply a higher level of logging to this traffic than to general traffic, so that the record of what assistant traffic contained, and what the guardrails did to it, is fuller. Logging settings are part of the platform's traffic configuration; raise them for the assistant's scope specifically rather than globally.
  • Audit trail. Guardrail decisions on this traffic are recorded in the audit log alongside every other guardrail decision, which is what makes the stricter treatment demonstrable after the fact. No extra step is required to produce the trail; Step 7 confirms it.

Scope each guardrail in the bundle to the distinguished traffic from Step 2 (the dedicated key, the marked attribute, or the routing policy) rather than platform-wide, so that general traffic is not subjected to controls meant for the assistant case. Where several guardrails apply to the same request, each is evaluated and a block from any one of them stops the request.

Step 4: start in a non-enforcing mode​

A bundle that has never run against real assistant traffic will eventually redact something it should not or block a legitimate request. Before the redact and block actions are allowed to affect callers, run the bundle in a flag-only mode against live assistant traffic for a period.

  • Set the guardrails in the bundle to flag rather than redact or block. Flag produces the same audit signal without changing what the assistant or the developer experiences.
  • Review the resulting audit-log entries to confirm the bundle is matching the traffic it should, namely real secrets and proprietary markers, and not colliding with ordinary code that merely resembles a pattern.
  • Resolve every false match and every missed match at this stage. A regular expression that matches more than intended is far cheaper to fix here than once it is rejecting a developer's requests.

Only once the bundle behaves correctly in flag mode is it worth promoting the actions to redact or block.

Step 5: promote the bundle to enforcement​

With the bundle validated, switch the actions from flag to the redact or block decided in Step 3, and confirm the scope still points only at the distinguished assistant traffic. From this point the gateway enforces the stricter controls inline on every assistant request: a detected secret is redacted or the request is blocked, the decision is logged at the tighter level, and an audit entry is written.

It is worth re-checking the scope explicitly at this step. A bundle that was scoped correctly in flag mode but is widened to platform-wide on promotion would begin blocking general traffic, which is exactly the surprise the flag-mode pilot was meant to prevent.

Step 6: coordinate with the developers who configure the assistants​

The distinction drawn in Step 2 lives partly on the developer side: in which API key an assistant is configured with, which header its configuration sets, or which endpoint it points at. If that configuration is wrong or absent, assistant traffic flows as general traffic and the stricter bundle never sees it.

  • Tell the development team which key, attribute, or path designates coding-assistant traffic, and confirm their assistant configuration uses it. The integration steps the developers follow are in Integrate the gateway with an app.
  • Make clear what the stricter bundle does, so a redaction or block during normal work is understood as policy rather than a malfunction. A developer who knows that a blocked request means a secret was about to leave the organisation responds very differently from one who reads it as a broken tool.
  • Establish how a new assistant or a new developer is brought under the same controls, so the distinction does not erode as the team and its tooling change.

The developer-facing view of attaching guardrails to a request path is covered in Protect requests with guardrails; pointing the development team at it gives them the other half of the picture.

Step 7: verify with a seeded secret​

The bundle is only proven once a request carrying a known secret has been sent through an assistant's path and observed to be blocked or redacted. This is the demonstration that the evaluation criterion asks for.

  1. Take the non-production secret prepared in the prerequisites: a clearly fake but realistically shaped token, never a real credential.
  2. Send it through the distinguished path, ideally from the configured assistant itself so the full path is exercised, embedding the seeded secret in a prompt that resembles real assistant content, such as a snippet of code containing the token.
  3. Confirm the outcome the policy intends: a redaction action removes or masks the token before the request reaches the model, while a block action rejects the request so the token never leaves the gateway.
  4. Open the audit log and confirm the corresponding entry: which guardrail matched, the action taken, and the scope and direction in which it fired, without the sensitive content itself being recorded.
  5. As a control, send a comparable request through a general (non-assistant) path and confirm the stricter bundle does not fire there, which proves the distinction from Step 2 is doing its job rather than the bundle catching everything indiscriminately.

A pass on both halves (the secret is stopped on the assistant path and ordinary traffic on the general path is untouched) is the evidence that the controls distinguish assistant traffic and enforce the stricter policy against it. The workflow for reviewing these entries in depth is covered in Audit platform activity.

What to do next​

Where to go next

Detect and redact sensitive data

The broader treatment of sensitive-content detection that this bundle draws on.

Configure custom guardrails

The rule types and match actions used to build the bundle.