Prompt injection security at Stilla

Stilla assumes an AI model can be manipulated or simply get something wrong. It may follow a prompt injection, misunderstand a legitimate request, confuse one destination with another, or choose an action the user did not intend. Our security model does not depend on the model always recognizing malicious instructions or making the right judgment. Instead, controls enforced outside the model limit what data it can access, where it can communicate, and which changes it can make.

No AI system can fully prevent prompt injection or eliminate model error today. This page explains the threat we design for, the boundaries Stilla enforces when the model is influenced or mistaken, and the responsibilities that remain with organizations using AI agents.

Our position

Prompt injection occurs when untrusted content — such as an email, document, web page, chat message, or tool response — contains instructions intended to manipulate the model. The model may treat those instructions as legitimate context and disclose information, contact an unintended recipient, or take an unwanted action.

Prompt injection is one cause of unsafe model behavior, but it is not the only one. A model can reach the same bad decision without an attacker. The safeguards described here are designed to constrain both adversarial manipulation and ordinary mistakes.

The greatest risk appears when an AI system combines three capabilities:

1. Access to private data
2. Exposure to untrusted content
3. The ability to communicate externally or make consequential changes

Simon Willison calls this combination the "lethal trifecta". Stilla has all three capabilities because useful work often requires reading private information, understanding content from outside the organization, and acting on a person's behalf.

We therefore treat the model as a fallible and potentially influenced component, not as the security boundary. The important question is not only why the model made a bad decision, but what authority remains available after it does.

Security boundaries

Runtime restriction policies

The model does not decide whether an operation is authorized. Stilla evaluates restriction policies in application code when the AI reads data, calls a tool, accesses the network, or executes a change proposal. These checks apply regardless of whether an instruction came from a person, an agent definition, an email, a document, a web page, or a tool result.

Policies can come from several layers:

• An organization policy applies to every interaction, including regular chats, shared-channel conversations, and agent runs.
• User-group policies are merged with the organization policy to produce the user's effective policy. At the same policy layer, a group setting takes precedence over the organization setting; when several groups define that layer, the most permissive group setting applies.
• An agent policy is evaluated in addition to the user's effective policy. Both must allow the operation, so an agent can be more restricted than its user but cannot use its own policy to bypass the user's restrictions.

Administrators can set a default policy for newly created agents. The user's effective policy remains active in regular chats where no agent policy applies.

Policies can govern an entire connection or an individual operation. This includes native Stilla integrations and the discovered tools on individual MCP and Pipedream connections. For example, an organization can permit GitHub reads and issue comments without permitting issue creation.

Resource-level rules

Resource rules separate what Stilla may learn from where it may act. An organization can keep broad read access while granting write access only for selected recipients, conversations, repositories, folders, drives, files, or canvases.

For example, a policy can allow Stilla to:

• Read any email, but send only to the current user, me@example.com, or recipients at an approved domain.
• Read only public Slack channels, keeping private channels and other direct messages out of scope, and send only to the user's own DM or a specific internal channel such as #incident-response.
• Use Google Drive broadly, while preventing access to sensitive documents in specific shared drives or folders.
• Read every GitHub repository, but comment or open issues only in one repository.
• Read across the Stilla workspace, but edit only canvases in a particular folder, with an exception for a specific canvas when needed.

Stilla evaluates every target independently. An email or calendar invitation with several recipients is allowed only if every address passes the policy; an injected extra recipient cannot borrow permission from an approved one.

More-specific rules take precedence over broader ones. A file rule can override its folder and drive, a canvas rule can override its folder, and an exact email address can override a domain rule. The decision uses the resource actually being accessed or changed, rather than relying on the model's description of what it intends to do.

Credential isolation

Stored API keys, refresh tokens, and long-lived OAuth credentials are kept outside the model's context. Native integrations authenticate on the server, and sandbox commands start without third-party credentials. Access to one user's account does not grant access to another user's account.

For tools that run inside Stilla's sandboxed computer:

• GitHub: Stilla mints a short-lived installation token scoped to the repositories named by the command and the minimum permissions required for the operation.
• Google Workspace: the sandbox never receives a Google OAuth bearer token. It receives a short-lived Stilla proxy credential tied to the user and canvas. A Stilla-maintained build of the gws CLI sends supported requests through Stilla's reverse proxy, where live user and agent restrictions are reloaded and enforced before Stilla attaches the Google credential on the server. Google Workspace writes use a separate change-proposal executor and are checked again when executed.

The model can request an operation, but it does not receive the stored credential or raw Google access token.

Network enforcement

Network controls apply to both Stilla's web tools and its sandboxed computer:

• Web search and fetch: Stilla checks whether web access is allowed and validates each requested URL against the effective network policy before fetching it.
• Sandbox computer: HTTP and HTTPS traffic passes through an authenticated egress proxy that enforces the effective allowlist and blocklist. A shell command cannot bypass the same boundary by using curl, a package manager, or another HTTP client.

Organizations can block network access, use Stilla's trusted-source defaults, define their own allowed destinations, or allow unrestricted access. User and agent network policies are combined using the more restrictive result.

Change proposals and human authorization

Stilla represents supported changes to connected systems — such as sending an email, posting a message, editing a calendar event, or creating an issue — as change proposals. A proposal starts pending and makes the intended change available for review.

A person can accept a proposal in Stilla. In workflows where an agent is allowed to execute proposals on its own, every applicable restriction policy must authorize the operation, and Stilla checks the current target resources again at execution time.

Some destinations add stronger safeguards:

• Slack Connect: an agent cannot send messages or add reactions in externally shared Slack channels on its own. A person must accept and execute the proposal.
• External email and calendar participants: an agent cannot execute a non-draft Gmail or Outlook Mail send, or a Google or Outlook Calendar invitation or update, involving an external address unless that person is an organization member or the address or domain is explicitly allowed by a resource rule. Otherwise, the proposal waits for a person.

Agent restrictions do not prevent an authorized person from reviewing and accepting a pending proposal in the app. Human acceptance is a separate authorization decision.

Third-party connections and MCP servers

Organization administrators can disable integrations whose data should not be available to Stilla. They can also restrict individual native, MCP, and Pipedream connections and tools.

An MCP server can itself span all three legs of the lethal trifecta. Stilla treats each server as a separate restriction-policy system. Stilla uses the server-provided readOnlyHint tool annotation to distinguish reads from mutations and routes tools it treats as mutating through change proposals. Because the server supplies this tool annotation and the tool implementation, connecting an MCP server extends the organization's trust boundary; organizations should connect only servers they trust and restrict their tools to the minimum necessary access.

What is automatic and what organizations configure

Examples under attack

A malicious email requests forwarding

An email contains hidden instructions telling Stilla to find sensitive messages and forward them to an attacker. A policy may allow the email to be read while permitting sends only to the user's own address. The proposed external recipient fails the resource check and the agent cannot execute the send.

A web page requests an upload

A page tells the sandbox to upload private files to another domain. Whether the model uses a web-fetch tool or tries a command-line HTTP client, the destination is checked against the effective network policy. A destination outside the allowlist is blocked.

A Slack message requests external disclosure

An organization can limit Slack reads to public channels and writes to the user's own DM or a specific internal channel. If injected content requests a post elsewhere, the resource policy rejects it. An agent also cannot execute a post to a Slack Connect channel on its own.

A document hides an additional attendee

A document instructs Stilla to create a calendar event and quietly add an external attendee. Stilla evaluates every attendee separately. Unless that external address is an organization member or is explicitly authorized by policy, the agent cannot execute the proposal.

Detection and response

Stilla gives the model a built-in path to report suspected abuse and unsafe use. In practice, Stilla regularly flags different kinds of potential prompt-injection attacks, which our team investigates. Reports identify the originating user and, when available, the chat or canvas where the concern occurred.

The reporting tool requests only a short, generic description and instructs the model not to include private user content, secrets, filenames, message text, or raw tool data. It does not automatically attach a transcript or tool output. What we learn from investigations informs improvements to our safeguards.

Reporting is a detection and response measure, not an authorization boundary. Restriction policies, credential isolation, network enforcement, and change-proposal checks remain active whether or not an attack is recognized or reported.

Limitations and customer responsibilities

Stilla's controls reduce the likelihood and potential impact of prompt injection, but they do not make the model immune to malicious content.

• Prompt injection may still influence the model's reasoning, output, or choice of attempted action.
• An operation that is within the effective policy remains available to the agent. Broad access creates a broader potential blast radius, so organizations should use least privilege for agents that process untrusted content.
• A person can authorize a proposal that an agent could not execute. Reviewers should check the content, destination, recipients, and target resources before accepting consequential changes.
• Third-party integrations and MCP servers have their own security properties. Organizations should connect trusted services and limit each connection and tool to what the workflow needs.
• Detection is not perfect. A suspected attack may not be recognized or reported, which is why enforcement does not depend on detection.

For higher-risk workflows, we recommend starting with no access or read-only access, granting only the required tools and resources, restricting network destinations, and requiring human review until the workflow's behavior is well understood. See Agent restrictions for configuration guidance.

This approach follows the central principle in Design Patterns for Securing LLM Agents against Prompt Injections: after an agent consumes untrusted input, consequential capabilities should be limited by controls the untrusted input cannot override.

For questions about Stilla's security practices, see our Trust Center, visit our Security page, or contact security@stilla.ai.