Guide ยท Agency operations # Keys by person, project and client Shared .env files make it impossible to say who can use what. Give every person and every agent its own identity, grant keys by client project, and load them for one command at a time. By Mitchell KellerNov. 10, 20266 min read A colonnade beside a lake. [Download the blank worksheet](https://www.joinlegion.io/downloads/access-by-person-project-and-client-access-map.md)[View Markdown](access-by-person-project-and-client.md) ## Key answer - Give each person and each agent or machine its own identity. Never share one login. - Grant keys per client project and environment, only where the work needs them. - Load keys into one command instead of writing them to a file an agent can read. - Access control decides who can use a key. It does not decide how much they can spend. On this page ## Shared .env files do not scale Every new tool means another key, and the easy path is to paste it into a file and pass the file around. After a few clients you cannot say who has which key, rotating one means chasing every copy, and an agent working in that folder can read all of them. I use Infisical to manage which people and projects can reach which keys. It is a secrets manager: keys live in one place, grouped by project and environment, and each person or machine gets access only to what it needs. Any secrets manager with per-project access and a command runner works for this method. How access flows Each person or agent has its own identity. That identity is allowed into specific client projects and environments, and nothing else. When work runs, the keys are loaded into that one command and disappear when it ends. Paid calls still pass through the campaign budget check, which is a separate control. - Identityone per person or agent - Project and environmentonly what the work needs - One commandkeys loaded, then gone - Budget checkseparate, on paid calls ## Six steps on one page - Inventory. List every service you hold a key for, which client it serves, and who owns it. - One identity each. Every person gets their own login. Every agent or server gets its own machine identity. If two things share a login you cannot tell them apart later. - Grant the minimum. Put keys in a project per client (or per internal system) and split by environment. Give each identity only the projects and environments its work needs. - Load for one command. Run the work with keys injected for that command, for example infisical run -- , instead of writing them into a file. - Revoke and rotate on change. When someone leaves a client or the team, remove their access the same day and rotate any key they could read. - Make paid use attributable. You should be able to say who ran a paid job, for which client and which campaign. ## A worked example A made-up agency with one client, ACME, and two internal systems. The people, codes and dates are invented. Access map (hypothetical) | Role | Client code | Service | Environment | Allowed | Owner | Review | Owner | All | All | prod, dev | Read and change keys | Owner | Quarterly | Campaign operator | ACME | Sending, enrichment | prod | Run campaigns | Owner | 2027-01-15 | Copy agent (machine) | ACME | Model API | prod | Load key for one run | Campaign operator | 2027-01-15 | Contractor | ACME | Enrichment | dev | Test lookups only | Campaign operator | End of contract The contractor never sees production keys, and the copy agent never sees the sending or enrichment keys. When the contract ends, one change removes the access and the enrichment key gets rotated. ## Close the side doors Controls only work if there is no easier path around them. Old .env files with direct provider keys let anyone skip the workflow, so find them and delete them once the keys live in one place. Check what a provider's own limits actually do: some stop spending, most only send an email. Some tools only read keys from a .env file in their folder, and most secrets tools can write one for them. Treat any file like that as readable by every person and every agent with access to the folder, and write it only for the tools that need it. ### Access is not spend The secrets manager decides who can use a key. It does not decide how much a campaign may spend with it. Put the spending limit in the workflow with a [campaign ceiling](/resources/give-every-campaign-a-ceiling). ### When this is the wrong tool A solo founder with one client and two keys is fine with a password manager. Set this up when a second person or your first agent starts running work. ## Get the blank access map Client access map (blank, Markdown) The access matrix from this guide, empty: role, client code, service, environment, allowed action, owner and review date, plus a rotation checklist for when an assignment changes. It holds no keys and never should. [Download the .md](https://www.joinlegion.io/downloads/access-by-person-project-and-client-access-map.md) ## Source notes This guide describes how I manage key access across my own agency work. Infisical is a third-party product; check its current plans and features on its own site. The access map is invented. The Legion course covers the setup we run in more depth for members; nothing here depends on it. ## Run your agency on agents you can check Get one useful GTM email a week. Then join the community on Skool. [Get the newsletter](https://waitlist.joinlegion.io/g/legion-waitlist) ## Start here: the agency path - [Give every campaign a spend ceiling](/resources/give-every-campaign-a-ceiling): budget control. - [Keys by person, project and client](/resources/access-by-person-project-and-client): access control. (this guide) - [One client code, one search boundary](/resources/one-client-code-one-search-boundary): client knowledge. - [Code Mode MCP: one tool surface for many tools](/resources/code-mode-mcp-one-tool-surface): code mode mcp. [Back to resources](/resources) ## Bring the GTM job you need done. Build the run you can check. Get one useful GTM email a week. Then join the community on Skool. Get one useful GTM email a week. Then join the community on Skool. [Get the newsletter](https://waitlist.joinlegion.io/g/legion-waitlist) [Join the community on Skool](https://www.skool.com/legion/about)