What Spellbook never receives.
Spellbook is self-hosted: it runs inside your own Kubernetes cluster, installed by you. It is never given your cloud credentials, never given a kubeconfig, and never given a shell. A developer who casts a spell holds no cluster permission of their own. The spell performs one bounded action on a service they own, and writes an audit record. Your actions and your data stay in your environment.
- Your cloud credentials
- No AWS, GCP or Azure keys. No IAM role in your account. There is no vendor account for them to be copied into, because there is no vendor-operated service in the path: you run Spellbook yourself.
- A kubeconfig
- You never hand cluster access to a supplier. Spellbook is installed into your cluster the way any other workload is, with the permissions you grant at install and none you did not.
- A shell
- No exec, no ssh, no port-forward, no break-glass console. The interactive path onto your nodes is not a feature that is switched off. It is not in the product. A developer cannot reach one, and neither can anyone who takes over that developer's account.
- A copy of your data
- A spell reads what it needs inside the cluster and answers in the surface you cast from. Nothing is shipped to us, and we hold no store of your logs, metrics or cluster state.
- A way back in
- There is no support tunnel, no phone-home, and no standing access for us. If we needed something from your cluster, we would have to ask you to fetch it.
One thing does leave the cluster, and it is the thing you asked for: the answer. Cast /scry checkout from Slack and the summary appears in Slack, which is a service you already trust with your incidents. No log is shipped anywhere, and no copy of your cluster is held outside it. If Slack is not somewhere you want an answer to land, cast from the terminal instead.
Where it runs
In your cluster, as a workload you deployed and can see. Spellbook is the thing that carries out the action, and it does so from inside the perimeter you already defend. Slack and the terminal are input surfaces to it, not a route around it.
The first spellbook is a set of operational actions for teams already running Kubernetes: deploys, restarts, and pulling debug data. It is self-hosted. There is no hosted or managed version of Spellbook today, and this page does not describe one.
The demo on the homepage is a simulation that runs in your browser. It is connected to no cluster, and it says so on its own chrome.
The permission model
A spell is a bounded action, not an access grant.
/revivify checkout-api performs one rolling restart of one workload the caster owns. There is no flag that widens it, no argument that turns it into kubectl, and no escape hatch underneath it. The dangerous version of the action is not hidden behind a confirmation dialog or a policy engine that somebody has to configure correctly. It does not exist for the user to get wrong.
Least privilege here is a default rather than a configuration. A developer holds the spells they were granted, and no credential at all. There is no combination of spells that adds up to a shell, and nothing to widen if someone asks nicely. The permission an attacker wants was never issued to the person they compromised.
Credential abuse appears in 39% of breaches, the most pervasive technique in the data (Verizon, Data Breach Investigations Report 2026). A vault, a rotation policy, and a just-in-time access request all work on the same assumption: that the credential has to exist. The strongest answer available to us is that it does not.
A refusal, in full
Ask for something you do not own and the spell tells you who does. The refusal is logged like any other cast.
spellbook · demo · simulation
/revivify payments-db
✗ You don't own payments-db
It belongs to the platform team. Spellbook won't restart it for you, and you hold no credential that could.
Ask in #platform, or have them grant you the spell.
refused · no permission held · logged
What one action leaves behind
Every cast writes one record: the ones that worked, the ones that warned, and the ones that were refused. A refused spell is as loud in the log as a successful one, because an attempt to act outside a permission is the more interesting event of the two.
The record is written by a workload you run, in your cluster, and it goes wherever the rest of your logs go. You do not need us to read it, and you do not need us to keep it.
audit record · example
- time
- 2026-07-13T14:33:07Z
- actor
- dev@example.com
- surface
- slack · #incidents
- spell
- revivify
- target
- checkout-api · namespace checkout
- action
- rolling restart · 3 pods
- result
- ok · 3/3 healthy · 41s
Who, what, where, and what happened, for an action nobody needed a credential to take. The exact fields are the ones the spell can actually vouch for; a record is worth nothing if it is a guess.
An AI agent is another employee
It gets its own identity and its own spells: the actions you trust it to take, and nothing else. It holds no credential and no shell, for the same reason the humans do not. Its casts land in the same audit record, attributed to it.
OWASP names excessive agency (an agent granted more capability, permission or autonomy than its task requires) as LLM06 in the Top 10 for LLM Applications. The mitigation it asks for is to limit the agent's tools and permissions to the minimum the task needs. A spell is that limit, expressed as the only thing the agent can do. A prompt injection can make an agent want anything; it cannot make it hold a permission it was never given.
97% of organisations that were breached through an AI tool had no AI access controls in place (IBM, Cost of a Data Breach 2025). An agent that can only cast the spells you granted it has exactly the blast radius of the employee you would have granted the same spells. That is the point of hiring it, and the point of bounding it.
The worst case
A page that will not say what can go wrong is not worth reading. Here is what can, and how far it gets.
A developer's account is taken over
The attacker can cast the spells that developer holds: read a diagnosis, restart a service that developer owns. They cannot exec into a pod, cannot read a secret, cannot reach a service the developer does not own, and cannot escalate, because none of those actions exist to be reached. The worst outcome available is a service being restarted when it should not have been: an outage, attributed and logged, rather than a breach. The same account holding a kubeconfig would have been a much worse morning.
An agent is prompt-injected
The same answer, and deliberately the same answer. The agent's reach is its spell list. An injection can make it try things; it cannot give it a permission, and every attempt is in the log.
Spellbook itself is compromised: a bad release, or our supply chain
This is the real one, and the honest answer is that it is not zero. Spellbook runs in your cluster with the permissions its spells require, so an attacker who fully controls it can do what those spells can do: restart workloads in scope, read the diagnostics they read. They cannot do more, because the service account does not hold more: no shell, no secrets, no credential for anything outside the cluster. The bound is the permission set you granted at install, and you can read it, pin the image you run, and take it away.
A spell is too powerful
The security of the system is the security of its spell set. If a spell can delete a namespace, then a compromised account can delete a namespace, and no amount of packaging changes that. Our answer is to build narrow spells and to refuse the wide ones. But you should read what you install the way you would read a role, and the install should let you.
We simply get it wrong
A rolling restart is still a restart. A spell that fires when it should not have fired causes downtime. What it does not cause is data loss: today's spells read and restart, and neither of them deletes anything.
What we have not done
Spellbook has not launched. There is no third-party penetration test, no SOC 2 report, and no compliance attestation, and we are not going to imply otherwise while there is nothing to show you. If one of those is the thing standing between you and running this, tell us on the waitlist. It is useful to know which one.
Questions a review asks
Does Spellbook need cluster-admin?
No. Spellbook runs in your own cluster with the permissions its spells require and nothing more. A spell like /revivify performs a rolling restart of a workload in scope; it holds no permission to exec into a pod, read a secret, or touch a service outside that scope.
Do you receive our cloud credentials or a kubeconfig?
No. Spellbook is self-hosted: you install it into your own cluster and it runs there. No cloud credential, IAM role, or kubeconfig is ever handed to us, and there is no vendor-operated service in the path between a developer and the cluster.
Can a developer get a shell through Spellbook?
No. There is no exec, ssh, port-forward, or break-glass console in the product. A developer holds a set of spells (bounded actions) and no cluster credential of their own, so an attacker who takes over that developer's account inherits the spells and nothing else.
How do you stop an AI agent from doing more than it should?
An agent is given its own identity and its own spells, exactly like an employee. It holds no credential and no shell, so the actions it can take are the actions it was trusted with, and every cast is attributed to it in the same audit record as a human's. This is the mitigation OWASP asks for under LLM06, excessive agency.
What happens if Spellbook itself is compromised?
The blast radius is the permissions its spells require: for today's spells, reading diagnostics and restarting workloads in scope. It cannot exceed them, because the permissions do not exist to be escalated into: no shell, no secret access, no credential for anything outside the cluster. The bound is the one you set at install, and you can read it.
Run it in your own cluster.
Spellbook is not open yet. Leave an address and we will come to you first. Tell us what your review needs.