ScriptKittyClouds
When an agent deletes or overwrites something through a web or cloud API, ScriptKitty keeps a copy first and puts it back like a file. Cloud cover is part of the free tool. The undo is our own copy, and the provider's own bin is only "a backup to our backup".
All of it is based on the user's own storage. The copies live on the user's own disks, and no cloud account of ours is involved. Regular people and small businesses use ScriptKitty free, and big companies pay.
coming Real cloud providers such as AWS, Google Cloud, Azure and GitHub are coming. The engine is built, and it has been tried only against made-up APIs. It has never been tried against a real cloud, and no account was used.
A go-between that holds the keys
A second small service, the cloud engine, sits between the agent and the web. It holds the real keys. The agent gets stand-ins that are useless anywhere else.
What happens to each kind of call
The engine treats a call by what it does to the thing at the other end.
| Kind of call | What the engine does |
|---|---|
| Read | Passes straight through. |
| Create | Written down, with the answer that says where the new thing is. A go-back reads it, keeps a copy and removes it. When the answer names no address or id, the thing is left and the go-back says why. |
| Delete | Waits while the thing is read and kept, then goes on. sk back and sk undo put it back like a file. |
| Overwrite | Waits while the thing is read and kept, then goes on. sk back and sk undo put it back like a file. |
The engine never stops a call. When no copy can be taken, the call goes on and the diary says so.
No connectors, one recipe
There is no connector per provider. One recipe serves every API: read the same address before the call, and write it back after.
The optional model-written recipe
Some kinds of call are beyond the plain recipe. For those, a model can write a recipe once. This is off unless the user sets it up, and it has fences. The model sees the shape of the call, never a secret or a body value. The recipe stays on that computer and can never leave the call's host.
What was measured
A real AI agent worked in a throwaway test VM, the same VM as in the file test. A made-up HTTPS "products" API was running inside that VM. It was a made-up API and not a real cloud. The cloud engine held the real token, and the agent was given a stand-in.
The agent deleted 23 products, changed 17 and made 1.
One sk back put the 40 deletes and changes back and removed the product the agent made. It read and kept that product first, and its output named the removal. Afterwards the API matched how it was before the agent started: nothing missing, nothing extra, nothing changed. The whole go-back took 4.4 s, measured once. The real token appeared 0 times. Ran once on this build (commit 7358a65).
The cloud engine also has its own check on the builder's machine, run against a fake API on that same machine. It passed 31 of 31 rows. Its AWS request signing matches AWS's two published examples (commits 526a42f, 03bbee3, 8c2d0c3 and 7358a65).
Not covered today
These cases are outside what the engine protects.
- HTTP/2 and gRPC, which are passed through blind and unprotected.
- S3 uploads signed chunk by chunk.
- Presigned links.
- A create whose answer names no address or id the engine can find (AWS-style XML answers, for one): the thing is left, and the go-back says so.
- An agent that was handed real keys directly.
- Changes made by a person in a provider's web console.
- Money a wrong call already spent.
- A thing made again getting a new id or address.
A second layer, planned
design only Nothing in this section is built. The plan is to turn on the provider's own versioning, soft delete and snapshots as a second layer, with a hold only for the rare thing neither can cover.
Next: what it cannot undo, or how it keeps things.