Solutions · Engineering teams
Provider changes your whole team can see, review and trust
When several people (and their coding agents) can change the services an app depends on, the questions become who changed what, who may change production, and how anyone would know. Ahena answers them with roles, approvals and an audit log, enforced in one place.
What gets hard as a team grows
Provider dashboards are built for one account holder, not for a team's process:
- Everyone needs a dashboard login or a shared key, so access is all-or-nothing.
- Production settings can be changed by anyone with a login, with no review.
- There's no single record of which provider setting changed, when, and by whom.
- A new teammate inherits a stack nobody fully documented.
What Ahena provides
Four roles
Owner, admin, developer and viewer. Developers connect and configure providers outside production; production changes need an admin; billing belongs to owners.
Approvals that a script can't give
Changes that matter (anything not safe in production, and billable or destructive changes anywhere) are approved only by a signed-in person in the dashboard. The CLI and agents can ask, not approve.
One audit log
Every change writes an audit event in the same transaction: who, how (web, CLI, MCP or CI), where and what. Events are append-only and hash-chained per organization, so edits are detectable.
Shared view of the stack
The Stack Graph, Doctor results, drift and plans are visible to everyone in the project; viewers can read and run Doctor without being able to change anything.
Checks in CI
ahena deploy-checkruns in CI with a read-only, project-scoped token and fails the build when the environment isn't ready to deploy.Controlled agent access
Each developer's coding agent gets its own restricted session that can propose changes but never approve them, reveal secrets or manage people.
Who can do what
| Role | Outside production | In production |
|---|---|---|
| viewer | Read everything except secret values; run Doctor | Same |
| developer | Connect and configure providers, write and reveal secrets, apply fixes | Read and run Doctor |
| admin | Everything a developer can | Connect, configure, secrets, billable and destructive changes |
| owner | Everything an admin can, plus billing | Same |
Good to know
- Roles are per organization. Ahena doesn't integrate with SSO or SCIM today.
- Approvals cover changes Ahena makes. A change someone makes directly in a provider's dashboard isn't approved, but drift detection reports it.
Questions
How do we stop production provider settings changing without review?
Give most people the developer role. Ahena requires an admin for production changes, and changes that matter are approved only by a signed-in person in the dashboard, with every decision in the audit log. Changes made outside Ahena show up as drift.
Can a teammate see the stack without being able to change it?
Yes. The viewer role can read projects, connections, secret names, Doctor results and the activity log, and run Doctor, but can't change anything.