FounderizerDeciding what an agent may reach
An agent you grant access to acts with that access. This is the part to think about before you grant anything, not after.
An agent with your GitHub App installed can write to the repositories you chose. An agent with a login from your vault can act in that service as that login. It is software, it is new, and it will sometimes be wrong in a way a person would not be.
One grant at a time
You decide what each agent may reach, separately. Not a role that comes with everything, and not a shell that can already reach whatever you can — one grant, for one agent, for the job it has. An agent with no grant for something has no path to it and no way to give itself one.
- Repositories: your own GitHub App, installed in your own organisation, on the repositories you choose. GitHub hands the private key to your hub. We hold no token, no key and no way in.
- Services: a login from the vault on your own machine. We never see it.
- Money: a limit in money terms, below which an agent may act and above which it must ask.
- Everything else: not granted, and so not reachable.
The record is a git history you can revert
Every change of access and every owner decision is a commit you can read and revert. That is the point of putting the record in git rather than in a log: you can see what was granted, when, by whom, and you can take it back the same way.
Anything it cannot do by itself, it asks you
A question on your phone, not a surprise afterwards. That is the behaviour on every use case on this site, and it is the reason a narrow grant costs you less than it looks: what falls outside it does not fail, it arrives as a decision.
What we cannot build around
The access itself. Give an agent the keys to something that cannot be undone and it may, one day, use them. No limit, record or question fixes that, and our terms say plainly that we are not liable for what your agents do with the access you gave them.
So the rule we would give a friend: grant the access the job needs and no more, start with the jobs whose mistakes are cheap, and read the record for the first week. The whole of what you carry is stated in full, with nothing kept back.
Questions
Can Founderizer reach my repositories or my servers?
No. Each customer installs their own GitHub App in their own organisation and GitHub hands the private key to their hub. We have no access to your server, your repositories or your data, and the product is built so that we cannot have it.
Where do the logins an agent uses live?
In a vault on your own machine. We never see one, and support will refuse a credential if you send it, because we cannot use it.
Can I take access back?
Yes. Every grant is a commit you can revert, and a GitHub App’s repository selection is yours to change in GitHub at any time.
The other guides
What makes an AI agent self-hosted
“Self-hosted” is said of setups that keep very different things on your side. Six questions show which parts of the work stay yours, and when a hosted platform is the better choice.
Which server should run your agents
The honest answer is: a small Linux server, and not your laptop. The reason is not power. It is the hours.
What always-on agents do to your AI plan
They can exhaust it. The limit is reached on your account, because it is your account they are signed in to. We cannot raise it and we do not pay it.
What it costs, what the agents actually do, and what you carry before you pay. Something wrong on this page? support@founderizer.com.