Who gets in where. And no password out of place.
Who it is for
For companies and public bodies where passwords live in spreadsheets, in emails and in someone's head, and where nobody can say for certain who has access to what.
The problem
The server password is in a message from two years ago. Several people share the same user. Someone left and can still get in. And now the team pastes keys into an AI assistant to get help.
How we solve it
We draw up the list of who gets in where and leave it as it should be: each person with their own user and only what they need. Passwords and keys move to a secrets manager and never leave it: not to files, not to chats, not to the AI model.
What it includes
Access inventory
Who gets in where, with which permissions and since when.
One user per person
No shared accounts, and a second factor wherever possible.
Secrets manager
Passwords and keys in one place, with a record of who reads them.
Joiners and leavers
When someone joins or leaves, their access is granted and removed from a list, not from memory.
Leaked credentials
We search for them in the code and across its full history.
A barrier for AI
Agents work without seeing the credentials.
How we work
We start with the inventory: systems, users and secrets, and where each one is today. We move the secrets to the manager and change any that have been exposed. After that, a regular access review: who still needs what. Who has access to each thing is always decided by a person in your company.
What we measure
Shared accounts remaining, access without a second factor, secrets outside the manager, credentials found in repositories and the date of the last access review.
How it is built
Secrets live in a secrets manager (we use Infisical), separated by project and by environment. Applications and deployments receive them at run time; they are not stored in the repository, in configuration files or in a chat. Every read is logged.
We search for leaked credentials across the full history of each repository, and in every change before it is merged. If one turns up, deleting it is not enough: it is changed.
With AI, a barrier blocks any agent command that would reveal a credential, so secrets never reach the model. Each agent gets the least access it needs and a closed scope. That barrier came out of what we learned applying the controls of the Spanish National Security Framework (ENS) in our own company.
Internal and pre-production environments sit behind identity-based access (Cloudflare Access, with the corporate sign-in), with no shared passwords. Where the application allows it, we add a second factor.
Frequently asked questions
What is a secret?
Any piece of data that grants access: passwords, API keys, certificates and tokens. They are all handled the same way: in the manager and nowhere else.
Do AI agents see my passwords?
No. A barrier blocks any command that would reveal a credential, and secrets never reach the AI model.
Do we have to change tools?
Not necessarily. If you already have a password manager, we start from it and put it in order. If not, we propose one.
What happens when someone leaves the company?
Their access is removed following a list and the secrets they knew are changed. That is what knowing who gets in where is for.
Also in Security
Security audit
Of your code and your applications, with every finding checked twice.
Penetration testing
Regular, authorised and with an agreed scope.
The next step
Tell us how you work today and we will tell you where to start.