Security
Least privilege, by construction.
A tool that can create and destroy infrastructure has to be careful about whose credentials it uses. This page describes what the code enforces. It makes no claim about certifications, because Foundry has none.
How it reaches an account
Credentials
- In each member account Foundry acts as that account's automation role, reached through assume-role with an external ID.
- The task role's own credentials are used for one call, the assume-role itself.
- In production, a client built with no account session installed fails. An account with no registered role cannot be acted on.
Access
Who can do what
- Every console command and agent tool passes a role check; some operations, such as applying an access graph patch, are administrator only.
- The agent tool surface refuses a call without a service token or an administrator sign-in.
- A CIDR conflict can be overridden only by an administrator, and the override is written to the audit trail.
- Remediation applies automatically only for a curated safe list of resource types; everything else needs an approval.
A Foundry that cannot act
Standby copy
A standby copy reads its database and refuses everything that would act on AWS, on another account, or on another tool. No role is assumed and no AWS client is built, so no code path can reach AWS from it. Renkara uses it to rehearse moving Foundry itself.
What this page does not claim
No audit, certification, or penetration test is recorded for Foundry, and this site does not claim one. Questions go to contact@renkara.com.
Contact
Questions about this tool?
Write to Renkara Media Group and a person will answer.