How Kelt Forge is built to be safe to run

A Forge AI run is scoped to the project it's working in: file access and shell commands are enforced to stay inside that project's own directory. Runs execute on Kelt Forge's own infrastructure, not your machine, and are bounded by a fixed turn limit and install/build timeouts rather than running indefinitely.

Forge AI commits directly to your checked-out branch and pushes to your own remote — there is no fork and no hidden service holding your code. Nothing is force-pushed, and nothing merges to your main branch without your approval. Every change is a normal, reversible commit.

Work that reaches your main branch waits for your explicit approval first. You see the plan before edits happen and the diff before it merges — at no point does an agent run silently push a change you haven't reviewed.

Secrets are stored server-side, never written into your codebase, and are not exposed to a project's own generated code. Credentials for connected services (such as GitHub and Vercel) are held and used server-side by Kelt Forge, not passed through to the agent's working environment as plain files.

Projects belong to an organization, and access to a project is scoped to that organization's membership — a signed-in user only reaches the projects their account is actually a member of.

You can let Kelt Forge manage a project's GitHub repository and deployment target on your behalf, or connect and use your own GitHub and Vercel accounts directly — the choice is yours per project, and either way the review and approval workflow above is unchanged.