Protect coding-assistant traffic

Enterprise Tier

Coding assistants reach a model through the same OpenAI-compatible interface as any other application, but their requests carry the organization's own source code, configuration that frequently contains credentials, and whatever sits in the buffer being edited. Tetrate Agent Router sits in the path of those requests, which makes it the place to isolate coding-assistant traffic and hold it to stricter guardrails than general application traffic.

---

Persona: Platform operator working in the Admin Console, 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 labeling depends on.

When this guide applies

Situation	What it covers
Coding assistants are in use and source code or secrets may be flowing through model calls	Isolating assistant traffic in its own project and holding it to a stricter guardrail
A policy requires that proprietary code never reach an external model unredacted	Intellectual property (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, guardrail providers, and 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 is isolated in its own project, distinct from general application traffic.
• A stricter guardrail, comprising IP and secret detection with a redact or block action, governs that project's 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 Console with permission to manage guardrails and API keys for the project, typically the super_admin role.
• A written statement of the policy the stricter guardrail is meant to enforce: which categories of content must not leave the organization 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 project boundary 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 behavior of a useful tool. 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.

Step 2: isolate coding-assistant traffic in its own project

Guardrails are project-scoped: a guardrail applies to all of its project's traffic, never to a single API key, header, or route. Stricter controls for assistant traffic therefore start with a project boundary: a dedicated project for coding assistants, with its own API keys and its own gateway.

• A dedicated project. Create, or designate, a project for coding-assistant traffic. The stricter guardrail is created in this project, so it governs every request routed through it and nothing else.
• Per-integration keys in that project. Issue each coding-assistant integration its own API key from the dedicated project. The same pattern of one key per integration is recommended for observability in Integrate the gateway with an app, so assistants frequently already have their own keys for that reason; this guide moves those keys into the dedicated project, or issues them from it.
• The project's gateway endpoint. Each assistant configuration points at the dedicated project's gateway URL with a key from that project. A key from another project is refused at that gateway, so traffic cannot drift between the two policy regimes unnoticed.

The boundary is only as good as the configuration on the developer side: an assistant configured with a general-purpose key flows as general traffic and never meets the stricter guardrail. Step 6 covers the coordination that keeps the boundary honest.

Step 3: assemble the stricter guardrail

The stricter guardrail is the set of controls applied together to the isolated traffic. It is built from the same guardrail mechanism used elsewhere in Agent Router, created in the dedicated project from Step 2, with the actions set tighter than they 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 (secrets check type); and the markers of proprietary source, such as internal codenames, license headers, or repository identifiers. Use the regexp guardrail provider with the Patterns library for structured secrets, builtin for keyword and subject-plus-term lists, and tetrate where semantic detection is needed. Where generated code must be rejected outside coding assistants, prefer ban_code or code check 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; a typical guardrail redacts incidental secrets and blocks 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 guardrailtrigger receives full content regardless of that setting. Both controls are org-wide rather than per-project, so a stricter guardrail cannot be given its own retention or verbosity; see Custom observability backends.

The guardrail lives in the dedicated project from Step 2, so general traffic in the organization's other projects 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 guardrail 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 guardrail 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 guardrail to enforcement

With the guardrail validated, switch mode from monitor to enforce for the redact or block actions decided in Step 3, and confirm the guardrail is enabled in the dedicated assistant project and in no other. 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.

Re-check the project boundary explicitly at this step. A guardrail that was validated in the assistant project in monitor mode but then recreated in a general-purpose project 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 boundary drawn in Step 2 lives partly on the developer side: in which API key an assistant is configured with and which gateway endpoint it points at. If that configuration is wrong or absent, assistant traffic flows as general traffic and the stricter guardrail never sees it.

• Tell the development team which project's keys and gateway endpoint designate coding-assistant traffic, and confirm their assistant configuration uses them. The integration steps the developers follow are in Integrate the gateway with an app.
• Make clear what the stricter guardrail 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 organization 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 boundary does not erode as the team and its tooling change.

The developer-facing view of how project guardrails apply 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 guardrail 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 dedicated project's gateway, 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. 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.
5. As a control, send a comparable request through a general (non-assistant) project and confirm the stricter guardrail does not fire there, which proves the project boundary from Step 2 is doing its job rather than the guardrail catching everything indiscriminately.

A pass on both halves (the secret is stopped in the assistant project and ordinary traffic in a general project is untouched) is the evidence that the boundary isolates assistant traffic and the stricter guardrail enforces 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.

---

Where to go next

Detect and redact sensitive data

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

Configure guardrails

The check types and actions used to build the guardrail.

Integrate the gateway with an app

How the assistants are pointed at the gateway, including the per-integration key boundary this guide reuses.

Protect requests with guardrails

The developer-side view to share with the team that configures the assistants.

Custom observability backends

Where guardrail-trigger records are delivered, and how much of the matched content each destination receives.