Protect coding-assistant traffic
Enterprise Tier
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 Agent Router distinguishes their traffic from everything else, how a stricter policy bundle, comprising intellectual property (IP) and secret detection with a redact or block action, 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 to 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:
| Situation | What it covers |
|---|---|
| Coding assistants are in use and source code or secrets may be flowing through model calls | Distinguishing assistant traffic and attaching a stricter policy bundle to it |
| A policy requires that proprietary code never reach an external model unredacted | IP and secret detection applied to the assistant's traffic with a redact or block action |
| A record is required specifically for AI traffic originating in developer tooling | Where the guardrail-trigger records for assistant traffic are delivered |
| The stricter controls need to be demonstrated before the evaluation is signed off | Verifying with a seeded-secret sample request |
For the general mechanics of detecting and redacting sensitive content (the check types, providers, and match actions that this guide reuses) see Detect and redact sensitive data and Configure guardrails. 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, comprising IP and secret detection with a redact or block action, is attached to that traffic.
- Where the guardrail-trigger records for that traffic are delivered, and how much of the matched content they carry, is understood.
- 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 with permission to manage guardrails and API keys for the project, typically the
super_adminrole. - 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 project guardrails, covered in Configure guardrails.
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. Agent Router offers three ways to draw the distinction, in roughly increasing order of how much developer cooperation each requires.
| Method | How the distinction is drawn | Trade-off |
|---|---|---|
| Dedicated API key | Each coding-assistant integration is issued its own API key, and the stricter bundle is scoped to that key | The cleanest signal; depends on developers using the issued key rather than a shared one |
| Request attributes or headers | A request attribute or header set by the assistant's configuration marks the traffic as assistant-originated | Flexible, but only as reliable as the configuration that sets it |
| Routing path | Assistant traffic is sent through a dedicated routing policy or path, distinct from general application traffic | Keeps the distinction in Agent Router 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 Agent Router 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 Agent Router, 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 rules that detect the categories the policy names: secrets such as API keys, tokens, and connection strings (
secretscheck type); and the markers of proprietary source, such as internal codenames, licence headers, or repository identifiers. Useregexpwith the Patterns library for structured secrets,builtinfor keyword and subject-plus-term lists, andtetratewhere semantic detection is needed. Where generated code must be rejected outside coding assistants, preferban_codeorcodecheck types and scope them carefully. See Configure guardrail providers and Configure guardrails. - 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.
- A record of what the rules did. Each rule evaluation writes a guardrail-trigger record carrying the rule and guardrail identifiers, the score, the action and mode, the stage, and the content type. No extra step produces it; Step 7 confirms it. Note that the record can also carry the matched text, which for assistant traffic means spans of source code: Settings → Guardrails governs what reaches the management plane (Full, Metadata only, or Off), and any custom observability backend subscribed to
guardrailtriggerreceives full content regardless of that setting. Both controls are org-wide rather than per-key, so a stricter bundle cannot be given its own retention or verbosity; see Custom observability backends.
Keep the bundle in the project that owns the assistant traffic, and distinguish that traffic as in Step 2 (dedicated key, marked attribute, or path) so general traffic in the same organisation is not subjected to assistant-only controls. Where several rules apply to the same request, each is evaluated and a block from any one of them stops the request.
Step 4: start in monitor mode
A bundle that has never run against real assistant traffic will eventually redact something it should not or block a legitimate request. Before redact and block are allowed to affect callers, run every rule in the bundle in monitor mode against live assistant traffic for a period. The procedure is the same for any guardrail and is described once in Validate in monitor mode before enforcing.
Two things are specific to assistant traffic:
- Ordinary source code resembles the patterns a secret rule looks for. Placeholder tokens in test fixtures, example connection strings in documentation blocks, and high-entropy strings such as commit hashes all produce matches that must be resolved before enforcement, not after.
- The pilot has to run long enough to cover the shape of real work, which for an assistant means more than one language, more than one repository, and the debugging sessions where data gets pasted into a buffer.
A regular expression that matches more than intended is far cheaper to fix in monitor mode than once it is rejecting a developer's requests.
Step 5: promote the bundle to enforcement
With the bundle validated, switch mode from monitor to enforce for the redact or block actions decided in Step 3, and confirm the rules still apply only to the distinguished assistant traffic in the project. From this point the gateway enforces the stricter controls inline on every assistant request: a detected secret is redacted or the request is blocked (HTTP 403), and each rule evaluation writes its guardrail-trigger record.
It is worth re-checking the distinction explicitly at this step. A bundle that was validated against assistant keys in monitor mode but then applied to unrelated project traffic would begin blocking general traffic, which is exactly the surprise the monitor-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.
- Take the non-production secret prepared in the prerequisites: a clearly fake but realistically shaped token, never a real credential.
- 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.
- 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.
- Confirm the guardrail-trigger record for that evaluation: which rule matched, the score, the action and mode, the stage, and the content type. Whether the record also carries the matched span depends on the controls described in Step 3, so this is the point at which to check that what reaches each destination matches what the policy allows for source code.
- 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. Note that a blocked response carries a correlation identifier, which an operator can later resolve to the rules that triggered and the content that caused the block; see Guardrails best practices and FAQ.
What to do next
- Detect and redact sensitive data: the broader treatment of sensitive-content detection that this bundle draws on. See Detect and redact sensitive data.
- Configure guardrails: the check types, providers, and match actions used to build the bundle. See Configure guardrails.
- Integrate the gateway with an app: how the assistants are pointed at the gateway, including the per-integration key boundary this guide reuses. See Integrate the gateway with an app.
- Protect requests with guardrails: the developer-side view to share with the team that configures the assistants. See Protect requests with guardrails.
- Custom observability backends: where guardrail-trigger records are delivered, and how much of the matched content each destination receives. See Configure custom observability backends.
Where to go next