We ask for execution rights. Here is exactly what that means.
Bladesmith changes things inside your business — a page in your repository, an email to your customers, a write to a tool you own. That is only reasonable if the permission model is narrow, legible and reversible. This page is that model in full, including the parts we have not built yet.
Nothing ships without you
Every capability that writes to the outside world is marked human-in-the-loop in the registry the runtime reads. It becomes a queued action with the status pending_approval, and only your approval moves it. Reads — analytics, Search Console, your repo's contents — run on their own.
Your keys stay yours
Provider keys are encrypted before they reach the database with AES-256-GCM; only ciphertext is stored, and the key lives in a server-only environment variable that is never exposed to the browser. The app shows you a hint, never the secret. Disconnecting deletes the stored credential.
One project cannot see another
Every user-owned table has Postgres row-level security enabled, with policies scoped to your own account and projects — isolation enforced by the database, not by application code that could forget. System-owned tables carry RLS with no policies at all: unreachable except by the service role.
Everything is on the record
Executed actions emit to an append-only event table that is service-role only. One request id ties a proposal, its approval, its execution and its measured outcome together — so 'what did it do, when, and why' is a query, not an investigation.
Every connection, spelled out
What each integration is allowed to do
This table is generated from the capability registry the runtime itself resolves against — it is the permission model, not a description of it. Reads run on their own; every write waits for you.
| Connection | How it authenticates | What it can do |
|---|---|---|
| Attiooff until you enable it | Your API key |
|
| Linearoff until you enable it | Your API key |
|
| DataForSEO | Your API keyread half on our key |
|
| Google Search Console | OAuth, scoped |
|
| Resend | Your API key |
|
| Instantly | Your API keyread half on our key |
|
| PostHog | Your API key |
|
| Google Analytics | OAuth, scoped |
|
| Stripe | Your API key |
|
| Statsigoff until you enable it | Your API key |
|
| GrowthBookoff until you enable it | Your API key |
|
| fal.ai | Your API keyread half on our key |
|
| Bannerbear | Your API keyread half on our key |
|
| Vercel Flagsoff until you enable it | Ours — no key of yours |
|
| Verceloff until you enable it | Your API key |
|
| App Store Connectoff until you enable it | Your API key |
|
| Google Playoff until you enable it | Your API key |
|
| AppTweakoff until you enable it | Your API keyread half on our key |
|
| iTunes Searchoff until you enable it | Ours — no key of yours |
|
Connections marked “off until you enable it” do nothing until a project switches them on. Where the read half runs on our own key, you are not asked for one — and that key never gains write access to your account.
Your repository
The narrowest access that still does the job
Connecting a repo is the biggest thing we ask for, so it is the thing we scope hardest.
- Only the repositories you pick at install. The GitHub App has no view of the rest of your account.
- Installation tokens are short-lived — about an hour — and refreshed on demand. Nothing long-lived is persisted.
- Read access is enough for the analysis. Opening pull requests additionally needs Contents and Pull requests write, which you grant explicitly; without it the code path refuses rather than trying.
- Every change arrives as a pull request on its own branch. You review the diff, you merge it, and git reverts it if you change your mind.
Your data
Where it goes, and where it stops
To the model
Producing a draft means sending the relevant context — your site copy, the funnel numbers, the code being changed — to the model provider that generates it. We do not train models on your content, and we do not sell it.
To other projects
The cross-project layer learns from the shape of results — this kind of action moved this metric for this kind of product — behind anonymisation thresholds. Your code, your customers and your copy are not what travels.
Out of the system
Deleting a project deletes it — the plan, the drafts, the measurements, the stored credentials. Not archived, not soft-flagged. Work already merged into your repository stays yours, because it was always yours.
The sub-processors your data can reach are exactly the connections in the table above, plus the platform we run on — listed in the privacy notice.
What we do not have yet
The honest half of a security page
SOC 2, ISO 27001
Not today. We are early, and saying otherwise would be the easiest lie on this page. If you need a compliance package to move forward, tell us what your procurement requires and we will tell you honestly whether and when we can meet it.
Third-party penetration test
Not yet commissioned. What we do have is a small attack surface, no long-lived provider tokens, database-enforced isolation, and an approval gate in front of every write.
DPA and sub-processor notices
Available on request while the standard paperwork is being finalised — email hello@bladesmith.io and we will send what we have.
Found something that looks wrong? Write to hello@bladesmith.io and we will answer.
Read the permissions. Then decide.
You can go a long way without granting anything at all: the plan, the analysis and the assets need nothing but a URL.
Connect GitHub insteadFree tier · no credit card · nothing is sent, posted or shipped without your approval