The single architectural decision that drives more security value than any other feature in Aegis is deceptively simple: being added to a project in Aero does not grant you any access to credentials in Aegis.
This sounds obvious. It is not practiced. Nearly every credential management tool we studied before building Aegis ties access to organizational membership. Join the org, join the team, see the team's secrets. The theory is that your teammates already trusted you enough to add you, so why add friction?
The answer is: because the person who adds a developer to a sprint board and the person responsible for who has access to a production database are often not the same person, operating on the same information, at the same moment.
The incident pattern
Here is the incident pattern that makes this design decision necessary. A contractor is added to a project. The project lead is thinking about velocity and tickets. Nobody is thinking about credentials. The contractor ships the feature. The engagement ends. Someone remembers to remove them from the Jira board. Nobody removes them from the credential store, because the credential store doesn't even know they were ever in the Jira board.
This is not negligence. It is the natural consequence of a system that bundles two distinct concerns - who is working on this project and who should see these secrets - into a single access model.
The fix is separation, not friction
Aegis requires an explicit, separate grant for credential access. It is not a second hurdle; it is a different door. A Security role or above in Aegis grants access. An engineer added to Aero for a sprint gets no automatic credential visibility. When the sprint ends, the project access expires naturally. The credential access is explicitly reviewed.
The audit log shows both doors, separately. When a SOC 2 auditor asks who had access to your production Stripe key in February - the answer is not everyone in the payments project. The answer is three names, with timestamps and ticket references.
What this costs
It costs one Slack message when someone needs access to a credential they don't have. In practice, we've found that teams adapt in about a week. After that, the security model becomes invisible - which is exactly where it should be.
The teams that push back hardest at onboarding are the ones who tell us, three months later, that they're glad we didn't let them configure it away.