Security & human control

Autonomy you granted, and nothing you did not.

Foundry is designed on one principle: access is not authority. Everything below follows from it.

The authority model

Access is not authority.

A DevOps agent with cloud access does not thereby have permission to provision unlimited infrastructure. A Growth agent with your social credentials does not thereby have permission to publish. Every permission is explicit, and enforced in the backend — not asked for politely in a prompt.

AUTONOMOUS

Foundry can

Done without asking. Nothing here reaches a customer or spends your money.

Research and discovery
Reads context. Changes nothing.
Requirements and user stories
Proposals you can reject at review.
Design drafts
Nothing reaches a customer until it is built and approved.
Writing code
Lands on a branch, not on production.
Running tests
Read-only against non-production environments.
Fixing low-risk bugs
Scoped to an open defect with acceptance criteria.
Writing documentation
Internal artefact.

APPROVAL REQUIRED

Foundry prepares and waits

The work is ready and the recommendation is stated. Nothing proceeds until you decide.

Major scope changes
Changes what you are paying for and when it lands.
Architecture changes
Expensive to reverse once built on.
Production deployments
Reaches your customers.
Destructive database migrations
Data loss is not recoverable by retrying.
Purchasing infrastructure
Spends your money. Cloud access is not a budget.
Connecting sensitive systems
Widens the blast radius of every later action.
External marketing publication
Speaks publicly in your name.
Material budget changes
A commercial decision, not a product one.

HUMAN ONLY

Reserved for you

No agent holds these at any permission level, and none can grant them to itself.

Granting or widening agent permissions
An agent must never be able to expand its own authority.
Deleting production data
Reserved. No agent holds this, at any permission level.
Legal and contractual commitments
Binds your company. Not delegable.
Removing a human approver
Protects the approval model itself.

Tool permissions

Every tool carries its own grants.

Permissions are not granted per agent, or per integration. They are granted per agent, per tool, per verb — and what is withheld is as visible as what is allowed.

GitHub read access does not imply permission to merge.
Azure access does not imply authority to purchase infrastructure.
Social account access does not imply permission to publish.

Tool permissions granted to each agent in the Acme Foods demo workspace
Agent	Tool	READ	CREATE	MODIFY	EXECUTE	DELETE
Product Lead	Planning	Granted	Granted	Granted	Withheld	Withheld
Product Lead	Work assignment	Granted	Granted	Granted	Withheld	Withheld
Product Manager	Requirements	Granted	Granted	Granted	Withheld	Withheld
Product Designer	Figma	Granted	Withheld	Withheld	Withheld	Withheld
Frontend Engineer	Repository	Granted	Granted	Withheld	Withheld	Withheld
Backend Engineer	Repository	Granted	Granted	Withheld	Withheld	Withheld
Backend Engineer	Database	Granted	Withheld	Withheld	Withheld	Withheld
QA Engineer	Test runner	Granted	Withheld	Withheld	Granted	Withheld
DevOps Engineer	Cloud environments	Granted	Granted	Withheld	Withheld	Withheld
Growth & Marketing Agent	Social accounts	Granted	Granted	Withheld	Withheld	Withheld

Grants shown are from the Acme Foods demo workspace. In your workspace you set these, and no agent can change them — widening agent permissions is a human-only action.

Security & trust

Built so that an autonomous team is still a bounded one.

Giving software agency over your product only works if the boundaries are real. These are enforced in the platform, not requested of the model.

Isolation

Product context, code and conversation never cross between organisations.

Workspace isolation: Everything is scoped to one workspace. Nothing leaks between them.
Environment separation: Development, preview, staging and production hold distinct credentials and distinct approval rules.
Repository boundaries: An agent reaches only the repositories its workspace was granted, at the permission granted.

Authority

Permissions are checked in application logic before an action runs.

Backend-enforced permissions: Never left to a system prompt to respect.
Role-based access control: Humans hold roles; agents hold scopes. Neither can widen its own.
Per-tool grants: Read, create, modify, execute and delete are granted separately for every connected tool.

Accountability

Every action is recorded with its reason, its approver and its result.

Audit logging: Agent, action, reason, tools used, what changed, approval state, approver and result.
Decision history: Every escalation, what Foundry recommended, what you chose, and what followed.
Verifiable completion: Work is complete when its acceptance criteria pass, recorded against the criteria themselves.

Platform security

Credentials are referenced, never held in context or passed to a model.

Secret management: Credentials are referenced, never stored in product context.
Session and API security: Authenticated sessions, validated input, and rate limiting on the surfaces agents reach.
Encryption: Data encrypted in transit and at rest.

On certifications. Foundry is early. We are not going to display a compliance badge we have not earned. If you need a specific control framework in place before you can adopt Foundry, tell us which one and we will be straight with you about where we are.

Start with one product

Tell Foundry what your business needs.

Create a workspace, describe the product, and watch the team pick it up. You approve what matters; Foundry handles the rest.

Start Building Request a Demo