How we handle your credentials and access
Most of the horror stories in AI-built software are not exotic hacks. They are a contractor’s shared login that never got revoked, an API key pasted into a chat two years ago, a domain registered under a freelancer’s personal email. We publish this page so you can see our standing policy before you ever hire us. It is short because the rules are simple, and it applies to every engagement.
Everything belongs to you
Every account, key, and secret involved in your system is created under and owned by your business: hosting, domain, repository, database, AI provider, all of it. If we find something registered under a builder’s personal account, moving it into yours becomes part of the work.
We are invited, never shared with
We join your systems as named individual users, Matt and Mike, under our own emails, with the least access that lets us do the job: read access for a review, write access only where we are building. When the job changes, the access changes with it.
No shared logins, ever
No shared logins, no “just use my password,” no exceptions, including for tools that make invites annoying. If a tool truly supports only one login, we will find another way in together or work through your screen. We will not hold the password.
Secrets live in your secret manager, not our files
Keys and tokens stay in your own vault: your host’s environment settings, 1Password, AWS Secrets Manager, whatever you already run. If you have none, we will help you set one up. Secrets do not appear in our repos, notes, chat history, or documents, and we will not put them in yours either: no keys committed to code, ever. If a secret has to reach us at all, it moves through your secret manager or a one-time expiring link, we treat it as compromised by default, and we rotate it when the work that needed it is done.
Access is written down
Every engagement has a shared access log, a simple document you can see at any time, listing each system, who at EVC has access, at what level, and why. If it is not in the log, we should not have it, and you should revoke it.
Offboarding rotates what we touched
When an engagement ends, you revoke our invites and we walk you through rotating any key we handled during the work. Not because we would misuse it, but because “the old contractor probably still has access” should never be a sentence anyone says about your business.
You can revoke everything instantly, and we plan for it
The handoff document is written so your system runs, gets fixed, and gets maintained with our access fully revoked. You can cut us off in minutes, any day, without asking us first, and nothing breaks. A vendor whose access you cannot afford to revoke owns you. We are not interested in owning you.
If we find an exposed secret, here is exactly what happens
Sometimes a review turns one up: a key in a public repo, a token in client-side code, a password in an old email thread. When it does, we tell you the same day, in plain words, with where we found it. We help you rotate it immediately, before anything else on the schedule. And we never test whether it could have been exploited beyond confirming it was exposed; we do not use your keys to prove a point. The finding goes in the readout with the consequence stated calmly, not theatrically.
Questions about any of this, including before you have hired us: ask. This page is the policy; there is no different one behind it.
Want to talk through how this works on your system?
Bring the app or workflow your team relies on. We’ll tell you whether EVC fits, and how the access plan would look for your setup.
Prefer email? matt@enterprisevibecode.com