Cuttlefish connects your real tools, code, infrastructure, and internal systems as governed capabilities — not a raw toolbox handed to a model. It learns what each system can do, decides what is safe before it acts, and keeps proof of everything it does.
Most AI tools wire a system in and let the model call it directly. Cuttlefish takes the opposite path: it brings your systems in as governed capabilities, where every action is named, classified, and answerable — so reach and control are both true at once.
Connect a system as a plain tool and the model gets whatever that tool can do — read, write, delete — with little between intent and consequence. The blast radius is the whole tool, and you find out what happened afterward.
Cuttlefish turns each system into named actions, and each carries a clear boundary: look only, draft only, ask first, or off-limits. The model never sees a firehose of raw commands — it sees a small, governed vocabulary of exactly what you allowed.
The usual choice is a sealed chat box you can trust or an open tool you can't. Cuttlefish removes it: your people get AI that works inside real systems, and your organization keeps the permissions, limits, and record on the whole time. This is the core of what makes Cuttlefish different.
Cuttlefish moves every system through the same path before it does anything real. Discovery and setup never act — work begins only once each action's boundary is known.
Cuttlefish takes stock of what a connected system exposes and confirms it is reachable and healthy — suggesting what it could help with, without touching anything yet.
The system's possible operations become a clean set of named actions the assistant can use — instead of a pile of raw commands no one can govern.
Every action gets a boundary before it can be used — look only, draft only, ask first, or off-limits — so the assistant sees safe affordances, never raw power.
Approved work runs in the real system, pauses for your OK when it matters, and leaves a tamper-proof record of what it touched and what changed.
When you connect a system, Cuttlefish reads a manifest: a plain description of the actions a system offers and the boundary on each one. It is how a team says, once and in one place, what AI is allowed to do here — read this, draft that, ask before changing this, never touch that.
A manifest lists the real things a system can do — read a ticket, draft an update, change a setting — instead of exposing the whole system as one all-or-nothing tool. Each action is something a person can read and understand.
Beside every action sits its rule: read-only, prepare-only, approval-required, or blocked. A new action that isn't described defaults to off — Cuttlefish does nothing it wasn't clearly allowed to do.
A manifest describes what a system does, never the keys behind it. Credentials stay in secure storage and are never shown in conversation or handed to a model — the connection uses them; nobody sees them.
Illustrative only — the host below is fictional and is not a live address. Real manifests are validated against your environment and your team's policy before anything connects.
environment:
id: client-operations
name: Client Operations
owner: Acme IT
host: acme-it.example # fictional — illustrative only
systems:
- id: ticketing
name: Ticketing
actions:
- id: read_ticket
boundary: read-only
- id: draft_ticket_update
boundary: prepare-only
proof: required
- id: update_ticket
boundary: approval-required
proof: required
- id: delete_ticket
boundary: blocked
- id: admin_console
name: Admin Console (in the browser)
allowed_pages:
- https://admin.acme-it.example
actions:
inspect: read-only
change_setting: approval-required
delete_resource: blocked
defaults:
unknown_action: blocked # if it isn't described, it's off
changes: approval-required
destructive: blocked
proof:
record: every-action # tamper-proof record of each resultRead it top to bottom and you can answer the only question that matters: what is AI allowed to do in this system, and what will it never do? That answer is set by your team, not by the model.
Every action a system exposes gets one of four boundaries the moment it is connected. That classification is what lets Cuttlefish work fast on the safe things and stay deliberate on the serious ones.
Look, don't touch. Cuttlefish can inspect or pull information but cannot change anything. Example: read the status of a deployment or summarize an open support ticket — nothing in the system is altered.
Draft and stage, but stop short of doing it. Cuttlefish can write a proposed change and lay it out for you, while the real action waits. Example: draft an update to a ticket or plan a configuration change you then review.
Ask first, every time. Before a consequential change, Cuttlefish pauses with a clear card showing exactly what is about to happen — and you allow, deny, adjust the scope, or run a safe dry-run. Example: apply that ticket update or push a setting change.
Off-limits, full stop. The action is either shown as unavailable or never exposed at all, and no approval can override it from inside a conversation. Example: deleting a resource your team marked as never-allowed.
An action that hasn't been described and allowed simply doesn't run. There is no path where an uncertain check quietly becomes a yes — when Cuttlefish isn't sure it's allowed, it does nothing and tells you why. You widen what a system can do on purpose, in one place, whenever you're ready.
For anything Cuttlefish does in a connected system, you can open a plain record of what happened — written for a person, confirmed genuine, and impossible to quietly change after the fact.
Every action leaves a record of what Cuttlefish used, what it changed, who approved it, and where the result went. You read it in seconds — no log diving, no jargon, no need to understand anything technical to know the work is sound.
Each record is sealed so that if even one detail were altered afterward, you would know. A quiet line at the top confirms the record is the original and hasn't been touched. The check runs by itself; you just see the plain result.
Everything Cuttlefish has done gathers into one running history, so audits, reviews, and "who said yes to that" questions have a straight answer. Reviewers and auditors can confirm the record is real and unaltered for themselves.
The plain reading is the default. If your security team ever wants the full technical confirmation behind a record, it's there behind an optional view — out of the way until the rare moment you need it. See how proof and control work.
Cuttlefish isn't a stripped-down personal app and a separate enterprise edition. It's one product with two postures — the same governed runtime, with an admin layer on top when an organization needs it.
Connect the tools you use, share a folder in look-but-don't-touch mode, and point Cuttlefish at models running privately on your computer. Local tools stay on your machine — the connection never travels to anyone else's servers, and credentials live in your computer's own secure storage. You see, repair, revoke, export, or wipe any of it, any time.
An admin brings people in through your existing sign-on, connects shared systems through a managed front door that hides credentials and keeps outbound access inside the boundaries you set, and decides what runs freely versus what pauses for approval. A read-only view shows what's running and the proof behind each result, and a single emergency stop can halt connected activity at once.
More on the team route: Cuttlefish for enterprise · for operators, IT & MSP teams and platform engineering.
Download Cuttlefish and connect a system in minutes, or talk to us about a guided pilot in your environment.