AINA

Our approach to safety

Shft acts for people. It reads their documents and the open web, it can hold access to their accounts, and it can send, change and spend. This page sets out the principles we build to, how each is enforced today, and the goals we are holding ourselves to.

The ten principlesAlso enforcedOur goalsReport a problem

Last updated 30 September 2026

We do not rely on the model behaving well.

A page can tell a model to ignore its instructions, and an email can ask it to forward a file. So the limits that matter are enforced by ordinary code around the model, where they can be tested. The model is treated as a component that can be wrong or be misled.

We keep two things apart on purpose. What we enforce today describes the software as it is now, and each item has automated tests in our codebase that fail if the behaviour breaks. Our goals describe what we intend to do next. A goal is not a claim, so it is drawn differently on the page and labelled as a goal.

Enforced todayGoal

Shft can still get things wrong, as any AI can. That is why these controls exist, why it shows you what it is about to do, and why every job leaves a receipt.

Ten principles, enforced in code.

This is what we enforce today. Each one is backed by automated tests that fail if the behaviour breaks.

Outside content is information, not instructions

Web pages, emails, documents, calendar invites, replies and anything else written by someone other than you count as outside content. Shft reads it as material to work from. It cannot give Shft orders, and it cannot authorise an action.

In practice

  • What arrives from outside is framed as information before a model sees it.
  • Work that starts from outside, such as a forwarded email, a reply link or an alert from a page watcher, begins in a cautious state from its first step.
  • Anything learned from outside content stays marked as untrusted, so old email or web text cannot later authorise a new action.

A run that has read outside content asks before sending

Once a job has read outside content, we treat the rest of that job as cautious. It cannot send anything, change your data, delete or buy without your approval, even if you have told the agent to act on its own.

In practice

  • This holds in every autonomy mode, including the most permissive.
  • Standing rules and “always allow” do not lift it.
  • Work handed to a specialist inherits it, so the caution cannot be shed by passing a job along.

You control how much it does on its own

By default, Shft asks before sending. You control its autonomy. Buying and deleting always require approval.

Every action has a risk level. A permission engine decides whether to allow it, ask you or refuse it, using the autonomy you set for that agent. The decision is made in code, not by the model.

What Shft does in each mode

Try it. Pick a mode, and say whether the job has read outside content.

Autonomy
  • Look things up and read your informationOn its own
  • Change your own data in your accountAsks you
  • Send something to another personAsks you
  • Delete or buyAlways asks you

In practice

  • A policy can refuse anything. Nothing can make a delete or a purchase silent.
  • Only you can decide an approval, and a step you decline sends nothing.
  • You can write standing rules in your own words, such as “invites to people at my company can go without asking”. A fixed parser reads them, not a model, and they cannot be used to allow buying or deleting.

Approvals cover exactly the call they were given for

When you approve something, your answer is stored with a fingerprint of the tool and its exact arguments, including who it goes to. It covers that call, once.

In practice

  • It does not carry over to another message, a routine’s later run or a specialist.
  • If a job resumes and a step now differs from the one you approved, you are asked again.
  • An approved call that failed is not tried again on a replay.
  • “Always allow” covers what the approval showed, such as those recipients or those sites, and not everyone.
Shft asks before it sends a calendar invite to Sam. It shows who it goes to, when and the title, with Approve and Decline buttons.
What an approval shows you, from the Shft web app. Your answer covers that one call.

Specialists cannot do more than their lead

Shft can hand parts of a job to specialist agents, such as one for research. Each specialist sees only the tools it was given, and the runtime checks that. It is not something written in a prompt.

In practice

  • For every call, a specialist gets the stricter of its own rules and its lead’s.
  • No approvals travel with handed-over work, so a specialist cannot spend an approval you gave the lead.
  • If the lead had read outside content, the specialist starts cautious too.
  • Specialists cannot hand work on, so there is no chain of delegation that could grow.

Credentials never enter a model’s context

Passwords, tokens and API keys are sealed in an encrypted vault (AES-256-GCM) and opened only in memory, only for the moment a tool call runs. They are not placed in prompts, task records, logs or data exports.

In practice

  • When a site needs you to sign in or enter a code, Shft hands you the browser and you do that step yourself. What you type is not shown to the model.
  • A saved login is used only on its own site, is never shown again, and every use asks you first.
  • If you bring your own AI keys, they are sealed too and never returned to you after you save them.
Shft's own browser reaches a sign-in form. A bar at the bottom says the sign-in is needed, that the step is the owner's, and offers a Take over button.
When a site needs a sign-in, Shft hands you the browser. That step is yours.

Guarded egress and private-network protection

Every request Shft makes to an address that you or a model supplied goes through one guarded fetch. It refuses addresses with embedded credentials, and private, loopback, link-local, carrier-grade NAT and cloud-metadata ranges, for both IPv4 and IPv6.

In practice

  • The address is checked inside the connection’s own DNS lookup, so the address that was checked is the address that is used. A name that later resolves to an internal address is refused.
  • Every redirect is checked again.
  • Once a job has read outside content, Shft can only open links that appeared exactly in your request or in an earlier result. It can follow a link but it cannot build an address, so injected text cannot make it carry your private data out in a URL.
  • Search queries follow the same idea. After outside content is in a run, every word of a query must be a plain word, a word you said, or a word from public content already read.

A receipt for every job

Each job leaves a receipt in your activity log: who asked, through which channel and agent, when, and how it ended. It lists the outside content that was read, what was changed or sent, what you approved, and any real money spent.

In practice

  • Receipts are assembled from durable records of what actually happened.
  • Only you can see them.
  • They never include credentials, tokens, vault contents or sign-in links.
A drawing of what a receipt lists. The real ones are in your activity log.

No training on your data by the model companies we pay

We use model providers on paid API terms that do not train on the data we send. Your memory, conversations and files live in Shft’s own database, not with a model provider. Changing the model changes who does the thinking, and never where your context lives.

In practice

  • Requests to OpenAI are sent with storage turned off.
  • Requests through OpenRouter require zero data retention.
  • Some direct providers may keep request logs for abuse monitoring for a limited time, because we have no zero-retention agreement with them. OpenAI, for example, may keep them for up to 30 days. So we are careful with this claim. We say that what we send is not used to train models. We do not say that nothing is kept on every route.
  • If you bring your own AI keys, the terms of your own account with that provider apply to that traffic.

Only what each step needs is sent to a model

Each step sends a model a core set of tools plus the areas the job uses, your request, the memories that matter and, on long jobs, the notes so far instead of every earlier step.

In practice

  • Background suggestions are written from your own words only, in a call that has no tools. They leave out mail, other people’s words and anything that looks like a password, key or card number.
  • Memory that came from outside content is kept out of the background jobs that tidy and suggest.

Also enforced.

Smaller rules that matter just as much in daily use.

  • Your data is yours

    You can download everything stored about you. Deleting your account removes it, along with its memories, tasks and sessions.

  • Nothing is shared between people

    Every request is scoped to its owner. Other people’s tasks, memories and approvals come back as not found.

  • No quiet repeats

    If a worker stops midway, the job resumes once from its last saved step. An action that was in flight is not retried. You are asked instead.

  • No false completion

    A job is only marked complete if it has a stored result. Otherwise it is marked failed.

  • Blocked steps say why

    When a rule refuses a step, the agent is told which rule and why. After three refusals in a row it stops and tells you what was blocked, in words written by code, not by a model.

  • One Pause

    Pause stops all of your agents. Routines skip their runs, watchers and background check-ins go quiet, and jobs in progress hold at their next step.

Our goals.

These are things we intend to do. None of them is done, and we have not set dates. We list them so you can hold us to them.

Goal

Publish our prompt-injection test results

We already test how Shft behaves when a page or an email tries to give it orders, as part of our own evaluation. We intend to publish the method and the results, including the cases where Shft fails, so that others can check them.

Goal

Independent review

We intend to have outside security reviewers examine the parts of Shft that decide what it may do, and to publish a summary of what they find and what we fixed.

Goal, later

Open parts of the trust layer

Later, we intend to open-source parts of the trust layer, which is the code that decides what Shft may do, so that anyone can read how it works and test it. We have not decided which parts, or the licence.

Report a problem.

If you think you have found a security problem in Shft or on this site, write to security@ainatechnologies.llc. Please include enough detail for us to reproduce it, and give us time to fix it before you share it more widely. The same contact is in our security.txt.

If something Shft did looks wrong, say no to it in the app, and tell us at hello@meetshft.com.