Platform SecurityRBACSecretsAudit

Ship fast.Keep the keysunder control.

Secure the platform layer behind your projects: identity, roles, permissions, secrets, policy checks, audit logs, and tenant boundaries.

Read security docs Back to products

Secrets exposed

Policy mode

strict

Audit

live

Security vault

tenant_9fa / production

locked

Know who is touching what.

Manage users, tenants, teams, project members, roles, permissions, invitations, and access boundaries from one security model.

RBAC

Identity

policy.check

deploy.production → allow

secret mode

raw values never leave vault

tenant.member.checkproject.permission.getsecret.ref.resolveaudit.event.appendpolicy.evaluatedeploy.production.guardbilling.admin.checkdomain.write.checkruntime.logs.readmember.invite.masktenant.member.checkproject.permission.getsecret.ref.resolveaudit.event.appendpolicy.evaluatedeploy.production.guard

Access matrix

Security starts with knowing who can touch the dangerous buttons.

Platform Security gives each role a real permission boundary. The goal is not to slow teams down. The goal is to stop one careless click from becoming a small fireworks show.

Maintainer

Can deploy, manage env, and operate services.

PermissionDecision

Deploy production

allow

Create preview deploy

allow

Read runtime logs

allow

Edit secrets

allow

Manage billing

deny

Invite members

allow

Secrets chamber

references, not raw values

sealed

DATABASE_URL

scope: production

referenced

secret://forgeon/production/database_url

XENDIT_SECRET_KEY

scope: billing

sealed

secret://forgeon/billing/xendit_secret_key

GITHUB_APP_PRIVATE_KEY

scope: git-service

sealed

secret://forgeon/git-service/github_app_private_key

JWT_PUBLIC_KEY

scope: platform

mounted

secret://forgeon/platform/jwt_public_key

Secrets by reference

Raw secrets should not become platform confetti.

Store sensitive values once, then pass controlled references to services, deploys, builds, and runtimes. The fewer places a secret appears, the fewer places it can leak.

Runtime injection

Secrets arrive only where they are needed.

Rotation ready

Update references without rewriting the whole platform.

Policy evaluator

Before the platform acts, the policy layer gets a vote.

Permission checks should be close to every sensitive operation: deploys, domains, secrets, billing, project settings, member management, and runtime controls.

developer

deploy.production

project/app-web

deny

maintainer

deploy.preview

project/app-web

allow

viewer

logs.read

runtime/app-web

allow

developer

secret.write

production

deny

Audit ledger

click an event to inspect

live

Audit trail

Security without memory is just confidence cosplay.

Sensitive actions should be visible after they happen. Audit logs help you answer who did it, where, when, under which scope, and whether policy allowed or denied it.

selected event · 12:47

secret.read

Actor developer-07 touched prod/DATABASE_URL and the decision was denied.

Security controls

The boring controls are what keep the exciting product alive.

Tenant isolation

Separate tenant resources, project access, billing scope, runtime controls, and audit visibility.

Least privilege

Give people the smallest set of permissions needed to ship without turning the platform into a free-for-all.

Secret references

Use references instead of scattering raw values across services, logs, clients, and deployment metadata.

Action-level checks

Sensitive operations go through policy gates before they mutate platform state.

Platform Security

Make the safe path the default path.

Lock down secrets, scope access, enforce policy, isolate tenants, and keep an audit trail for the actions that matter.

identity → policy → secret → audit

Open docs Explore products