AI guardrails are sold as a solution to keep models behaving as intended - but it can be hard to figure out what you’re getting. The problem starts with the word itself. "Guardrails" means different things depending on who's selling them. Some vendors use it for simple prompt filtering, others bundle in entirely different controls and call it "guardrails" because the word sounds reassuring. Without a shared definition, buyers can't easily tell what they're actually getting.
What AI security guardrails look like in practice
A guardrail designed to prevent auth secrets from leaking in model output intercepts every token sent back by a model and compares it against a list of known secrets
A guardrail designed to stop prompt injection might use an AI judge to classify incoming text and reject content that appears to contain instructions aimed at overriding the system prompt
A guardrail designed to stop an agent from hacking a third party might run that agent in an isolated sandbox, allowlisting only specific network connections
Why each of these guardrails can fail
The agent could be asked to change one character in the secret and return it
The agent might not follow its instruction
The AI judge might make an incorrect classification
An agent might use allow listed access to hack a third party’s infrastructure in order to meet its goal
7 questions to ask any vendor about their guardrails
When somebody tells you they use “guardrails” to make their AI tools secure, ask what enforces them and what happens when they fail:
Do any guardrails rely on skills or instructions? What ensures the agent follows them every time? Instructions guide behavior, but they don’t prevent an agent from taking an action it still has permissions to perform.
Do any guardrails depend on the agent using a particular tool? What ensures that tool runs whenever required, and can the agent bypass it? Agents can choose to skip safety checks if they aren’t enforced.
Can the agent access information it should never share with a third party? What prevents direct disclosure, encoded output, or messages that reveal the information indirectly? Matching known secrets in output won’t catch every way to expose them.
Do any guardrails rely on an AI judge? What happens when it’s wrong, and how do you audit its decisions? A second model is not a guarantee of safety.
How do you keep authentication secrets out of the agent’s reach? Can the model or its generated code read them? An agent may need to authenticate a request without needing access to the credential itself.
How do you prevent unauthorized internet access? Are restrictions enforced outside the agent, including for code it generates? Asking an agent not to make a connection is different from blocking it.
If an incident happens, can you trace what happened? Are API calls and outputs logged outside the agent’s execution context? Independent record of what the system did is needed, not just the agent’s account of it.
Boring security basics still work
The only way to be sure that an agent can’t run riot with your secrets and systems is to take the same old boring but critical security steps that we have followed forever: enforcing least privilege, restricting available tools, and requiring human approval for high-risk actions.
If a model never has access to your secrets, it can’t leak them
If a model doesn’t have a way to interact with your high-risk systems, it can’t be prompt-injected into harming them
If a model doesn’t have a route to third-party infrastructure, it can’t hack those third parties.
How Tines 3B is secure by design
These are the same boring, battle-tested security principles behind how we've built Tines 3B to be secure by design:
Models never handle secrets - they are injected by a proxy outside the execution context so that models are never aware of them
Agents write code that runs in isolated sandboxes, with access restricted to explicitly permitted software, network connections, and data
Security teams own tool access, and tools are only ever exposed to agents which should have permissions to run them
Every API call an agent makes, and all of its output, is logged outside of its execution context for auditing
Guardrails vs. constraints
This is the difference between having a guardrails-focused security posture, and having a security posture that actually protects your most important workflows. Guardrails try to influence agents to behave well, while Tines 3B actually constrains what the system can do in the first place.
AI security should assume that the model is a hostile, untrusted actor. Not because it’s malicious, but because you can’t prove that it isn’t. Prompting it to behave well doesn’t change that assumption, only removing its ability to cause harm does. The secure response is limiting their authority, isolating execution, protecting credentials, and preserving an audit trail. Tines 3B is built as a governed execution environment, designed for that assumption from the start.