Most teams adopting AI in their workflows understand that LLMs do not behave like traditional software. The same input does not always produce the same output, and even when it does, the model can be wrong, manipulated, or misled.
Hallucinations happen even without adversarial input. Air Canada learned this in 2024 when a tribunal ordered the airline to honor a bereavement-fare refund policy its support chatbot had invented out of thin air. Like everyone, we sometimes see a smaller-scale version of the same problem when working with AI. I have seen models occasionally generate confident references to Tines formulas that don't exist in the product.
In a previous post on navigating AI risks written by my teammate Conor, we explored why prompt injection risks persist and why implementing guardrails alone is an insufficient approach to take.
While Conor closed out his blogpost by sharing five principles for building safe AI workflows, I will further expand on those principles here. I will explain what they mean in practice, what good and bad implementations look like, and how building in Tines as your AI interaction layer makes it easier to implement them by default.
1. Separate trusted instructions from untrusted input
Your workflow's logic, system instructions, prompts, and routing rules are under your control. You or a colleague authored them. Data arriving via emails, tickets, webhooks, and APIs are not. It's important to separate these two categories of input when building your workflows. The AI Agent action sits at the point where both meet, and when untrusted input can reshape trusted instructions, the workflow itself becomes the prompt injection surface.
In a well-designed workflow, the LLM receives a fixed system prompt authored by the builder, with user-supplied data being passed as a separate input parameter. The model then processes the data according to the instructions, rather than as a single string with no structural distinction between the two.
In Tines, AI actions enforce this separation at the configuration level. The builder defines system instructions in a dedicated field, which are then sent to the model as system-level messages. Event data from upstream actions then enters as user-level content in a separate prompt field. The Tines story itself reinforces this boundary where untrusted data cannot change which tools are linked or alter the workflow structure. Separating instructions and input is a design choice, and one we encourage every builder to make. Tines provides the structure to keep them apart by default.
However, this alone does not make prompt injection impossible. LLM APIs structure each request as a sequence of messages tagged with a role (system, user, assistant, tool), and the model uses these roles to weigh how much authority to give each piece of content. Inputs deliberately crafted to exploit model behavior can still influence the model regardless of which role they arrive under. Examples include content that impersonates system messages, uses role-play framing to override instructions, or hides directives inside data the model is asked to summarize. But an attacker has to work against the structure of the system rather than simply appending instructions to an undifferentiated prompt string. And even if the model is compromised, what it can actually do is constrained by the next principle.
The same risk applies to anything an agent reads at runtime. A tool that fetches a webpage, summarizes an email, or queries a third-party system returns content the model treats as part of its context, and an attacker who controls that content controls another input channel into the model.
2. Set deterministic boundaries on tool access
The person building the workflow, not the model, should always decide which tools are made available and what they can do. In Tines, an AI Agent action can only invoke tools the builder has explicitly linked to it. The builder can lock specific input values on a tool, so even if the model decides when to call it, certain parameters cannot be changed. For example, if a tool sends a notification, the builder can leave the message field open for the model to populate at runtime but pin the recipient field to a fixed address.
The model chooses what to say and when to trigger the action, but who receives it is set at build time and not up for negotiation.
The builder can also guide the model's output toward a defined JSON schema via the output structure option, encouraging structured, predictable responses for downstream actions (see the AI Agent action’s configuration docs for more info). In Tines, custom tools and Send to Story let the builder route execution into scoped processes that run on fixed logic, not model discretion.
None of this prevents the model from producing unexpected content within its allowed scope, but it ensures the scope itself is defined by the builder and enforced by the platform.
3. Apply minimal privilege to model-driven actions
Every action an LLM can trigger should operate with the least access required. When building, scope credentials, limit write permissions, and constrain the blast radius so that even a fully compromised model step cannot escalate beyond its boundaries.
In Tines, credentials are never exposed directly to the model. When a tool is presented to an AI Agent action, credential inputs are stripped from the tool definition entirely. The model cannot see, select, or modify the credentials a tool uses; they’re configured by the builder on the action itself, outside the model's reach.
Credentials can be further restricted with domain allowlists, limiting which hosts they can authenticate against regardless of how the action is invoked. Credentials are scoped to teams with explicit sharing controls, and tenant-level egress controls restrict which external destinations any action is allowed to contact.
The model cannot choose its credentials, the credentials are domain-restricted, and the network layer enforces where requests can go.
No single control is sufficient on its own, but together they ensure a compromised model step operates within a tight corridor of access.
4. Build in human oversight at critical junctions
Not every step needs a human in the loop, but sometimes you need to include a human checkpoint for high-impact or irreversible decisions.
In Tines, pages are a native action type designed for human interaction. A builder can route the output of an AI Agent action through a page where a team member reviews, edits, or approves the result before it triggers downstream actions. AI Agent actions can also operate in chat mode, where a human converses with the agent directly rather than it running fully autonomously, keeping a human in the conversation for more sensitive use cases.
Beyond individual runs, Tines also supports change control at the story level. Modifications to workflows, including AI-powered ones, can require approvals before promotion to production.
Oversight extends not just to what an AI Agent action does at runtime, but to who can change what it is allowed to do.
5. Assume prompt injection will happen
We believe that teams who design for a world where prompt injection never occurs, are sadly the most exposed and at risk.
While the previous four principles addressed containment, auditability also plays a key part that cannot be overlooked. Admins must always be able to check what their AI-powered workflows are doing and be able to easily investigate when something looks wrong.
In Tines, audit logs capture AI activity, including which tools were invoked and by whom. The AI overview page gives admins a centralized view of all AI Agent actions, their linked tools, MCP server connections, and conversation history across the entire tenant. This is a searchable, filterable dashboard purpose-built for understanding how AI is being used across workflows.
Builders can also set per-action thresholds on token usage that notify the team or automatically disable the action when exceeded. At the tenant level, admins can set credit allocations per team, blocking AI invocations when limits are exceeded.
While none of these measures prevent prompt injection, they are designed for a world where injection is assumed, the blast radius is constrained, humans stay in the loop, and every AI-driven action is traceable and auditable.
Get started building secure, intelligent workflows today for free in Tines.