Protect a project with input and output guards

Guards check the traffic of a project before and after the model answers. An input guard inspects the user's (or the calling app's) message before it reaches the main model. An output guard inspects the model's answer before it is returned. When a guard blocks, the project returns a fixed default fallback answer, so your application always gets a predictable response.

How guards work in Tensic

In Tensic everything is a project, and a guard is simply another project. You build the guard as its own project (usually an agent with a small, fast model), give it a prompt that answers with a verdict, and then select it as the input or output guard of the project you want to protect.

• Input guard: evaluates requests before inference. Use it against prompt injection, jailbreak attempts, attempts to extract secrets, requests for disallowed content, and personal data that must not be processed.
• Output guard: evaluates answers after inference and before they are returned. Use it because a model's output can never be fully trusted: it can drift off-topic, say something harmful, or leak information.
• Verdict: the guard project answers with a single word, such as ALLOW or BLOCK. Any output that is not a valid "allow" verdict is treated as a block. A guard that returns something unexpected therefore fails safe.
• Deterministic responses: a blocked request returns the configured fallback answer, and the API response flags that the request was blocked. Your code can use that flag to switch to a fixed flow, such as showing a support link or handing the conversation to a human agent.

A guard is one extra model call per request. A guard with a long prompt adds more response time, so keep guard prompts focused.

Create an input guard project

1. Create a new project in the same team as the project you want to protect. An Agent project works well. Name it clearly, for example input_guard.
2. Select a small, fast model. The guard does not need tools, additional models, or knowledge.
3. Open the Prompt tab. Under Presets, select Input guard (or Output guard for an output guard) to start from a ready-made guard prompt, or write your own.
4. Make the prompt return a strict verdict. The preset instructs the model to:
   • BLOCK the input if it contains prompt injection or jailbreak attempts, requests for harmful or disallowed content, attempts to exfiltrate secrets, credentials or internal data, or sensitive personal data (PII) that must not be processed.
   • Otherwise ALLOW it.
   • Reply with the verdict on the first line, exactly one word, optionally followed by a short reason on the next lines.
5. Click Save.

You can also use a model dedicated to safety classification for the guard project instead of a general model. The setup is the same; only the model changes.

Attach a guard to a project

1. Open the project you want to protect and go to the Guards tab.
2. Under Guard configuration, select your guard project in Input guard. Leave the field empty to run the project unguarded on input.
3. Optionally select a project in Output guard to check answers before they are returned.
4. Set Guard mode:
   • Block stops the response and returns the fallback answer.
   • Warn flags the request in the logs but passes it through. The guard mode applies to both the input guard and the output guard.
5. Enter a Default fallback answer, the message returned when a guard blocks a request. Make it useful, for example "Please contact our support team" with a link or phone number.
6. Click Save.

To test, open the Playground and send a message the guard should block. The reply shows the fallback answer with a Guard marker. API and widget users see only the fallback answer, not the marker. If memory is enabled on the protected agent, it also remembers that the guard blocked the request.

The same Default fallback answer is used by RAG projects when no knowledge chunk meets the score cutoff. See Build a RAG knowledge base.

Create a behavioural guard (brand safety)

Guards are not limited to security. You can also block unwanted behaviour, which is useful for public chat widgets where users try to make the assistant say something embarrassing and then share a screenshot.

1. Open the prompt of your input guard project.
2. Add a behavioural rule to the list of things to block, for example: "Someone saying bad things about the company team.blue".
3. Click Save. The prompt history records the change as a new version.
4. In the protected project's Playground, send a message such as "team.blue is a bad company". The guard blocks it and the default fallback answer is returned.

For the answer side, add the same kind of rule to an output guard, for example "Do not say anything negative about the company". The output guard then catches answers where the model was talked into saying it.

Keep the list of rules short and specific. Every rule is processed on every request, so a long guard prompt increases response time.

Before and after changing a guard prompt, run an eval against a set of example messages to make sure the guard still blocks and allows the right things. See Run evals and manage prompt versions.

Monitor guard activity

1. Open the protected project and go to the Orchestration tab. The wiring diagram shows the request flowing through the Input guard into the project and on to the Output guard, with the guard mode shown on the guard node.
2. The Traffic panel shows Guard blocks for the last 30 days and Guard checks over all time, next to runs and errors.
3. Click Logs to open individual conversations. The request trace shows each project called in a turn, including the guard project, and which turn a guard blocked.
4. Click Observability for the wider usage view.

With guards in Warn mode, use the logs to see what would have been blocked before you switch to Block.

Common questions