Skip to content
Method: every claim tracked, reviewed every 30–90 days, marked Holding, Partial, or Not holding. Drafted by Claude; signed off by Peter. How this works →
OPS-074pub24 May 2026rev24 May 2026read5 mininOperators

Your AI assistants already have identities. They just don't have yours. A 5-step NHI starter kit for 5-15 person teams

If your small team is running Claude Code, Cursor, Windsurf, a customer-service bot, or any internal automation that calls a SaaS API, each of those is a non-human identity acting in your environment. Most 5-15 person teams have one personal API key per founder being shared across three or four AI tools, no rotation cadence, and no plan for what happens when someone leaves. The five-step starter kit below brings the team to a defensible posture in three hours of work, no CyberArk budget required.

Holding·reviewed24 May 2026·next+23d

Your team is small. You run AI tools on paid client work. Each AI tool acting in your environment is a non-human identity, whether you set it up that way or not. The five-step kit below brings the team from “one personal API key per founder shared across four tools, never rotated” to a defensible posture in three hours of work. No CyberArk budget. No new tools to buy in most cases. The tools you already pay for (password manager, calendar, spreadsheet) are the kit.

The enterprise version of this question is at AM-167, which covers the four-clause gap that most 2026 agentic AI MSAs leave open at the enterprise procurement layer. The small-team version is operationally smaller and faster.

Why this is not optional in 2026

Three reasons.

Enterprise clients now ask about it. Q2 2026 enterprise procurement questionnaires routinely include a question about how the vendor manages credentials for AI agents acting on client data. An agency that has run the kit answers in two sentences. An agency that has not loses the contract or spends a week negotiating around the question.

Insurance terms are tightening. Cyber insurance renewals in 2026 are increasingly conditioned on documented credential-management practices, including for non-human identities. The five-step kit is a credible answer to most insurer questionnaires; the absence of one is increasingly an explicit policy exclusion or premium loading.

The blast radius is wider than it used to be. A 2024 shared API key gave an attacker access to the SaaS account it authenticated to. A 2026 shared agent credential gives an attacker the agent’s full action surface, which in a typical small team running Claude Code, Cursor, or a customer-service bot includes reading the codebase, writing commits, opening tickets, and sometimes transacting. The same procedural failure produces a larger consequence than it did two years ago.

The five steps, in order

Full how-to schema is in the FAQ. The body version is shorter.

Step 1: Inventory. Open a spreadsheet. List every AI tool acting in your environment, where it runs, the credential it uses, who issued it, where it lives, the last rotation date, and what it can reach. Walk each engineer’s laptop and each shared service. The common discoveries are uncomfortable and tractable: one founder’s OpenAI key is in five places; the GitHub PAT has full-repo scope and has never been rotated; the Zapier integration was set up by someone who left.

Step 2: One credential per agent, smallest scope. Replace each shared personal credential with an agent-specific one. Anthropic and OpenAI both support multiple workspace API keys; use one per agent so attribution works. GitHub PATs become fine-grained tokens scoped to the specific repositories. SaaS integrations use the vendor’s documented service-account flow. The blast radius of any single credential drops by an order of magnitude with no functional change.

Step 3: One vault, everything in it, nothing outside it. Pick the secrets vault the team already pays for. 1Password Business, Bitwarden, Doppler, AWS Secrets Manager, any of them works. Move every credential from the inventory into the vault. Update each tool to read from the vault on startup. Remove credentials from local .env files, shell profiles, chat histories, CI configurations. The vault is the single point of revocation; if a credential is not in the vault, it is not under control.

Step 4: 90-day rotation cadence on the calendar. 90 days is a sensible starting cadence for long-lived API keys at the 5-15 person scale. Short-lived tokens (OAuth refresh, mTLS certificates from a small internal CA) are configured for short-lived issuance and do not need a calendar entry. The calendar entry has one named owner and takes 1-2 hours per quarter. Without the calendar entry, the rotation does not happen.

Step 5: One-page leaver and revocation runbook, tested once. Two scenarios: someone leaves; a credential is suspected compromised. The runbook lists the credential classes to revoke, the order, the time-to-revoke target (under 4 hours for the leaver case; immediate for compromise), and the verification step. Test it once on a low-stakes credential: revoke, confirm the agent fails closed, re-issue, document the timing. The test is the only proof the runbook works.

What “good” looks like at 5-15 people

A team that has run the kit can describe their NHI posture in four sentences to a client, an insurer, or a security auditor.

We inventory every AI tool acting in our environment and the credential it uses. Each AI tool has a dedicated, non-personal credential with the smallest scope it needs to function. All agent credentials live in (vault product); none are stored on engineer laptops or in shared chats. Credentials rotate on a 90-day cadence with a named owner, and we have a documented and tested revocation procedure.

Four sentences cover what a CyberArk-grade enterprise programme covers, scaled to a team that does not have an identity-governance function. The procurement-grade answer is the same shape; the scale is different.

What this does not cover

The kit handles the credential-management layer. It does not handle the upstream protocol-stack question (which is at OPS-076, the small-agency sibling of AM-169), the data-residency layer (at OPS-054 for solo EU developers), or the contract-disclosure layer (at OPS-065). The credential kit is the cheapest and highest-leverage move; the other layers compound on top of it.

The enterprise reading at AM-167 is reading-the-table material for an operator selling AI services to enterprise clients. It tells you the language the procurement team across the table is using and the four-clause set they will be looking to see in your subcontract or partnership terms.

Calendar this Monday morning

Three hours of focused work, one person doing it, the team’s existing tools. The inventory is the longest step (an hour to ninety minutes for a 5-15 person team). Per-agent credentials and vault setup are forty-five to sixty minutes. Calendar entry is five minutes. Runbook draft is thirty minutes; the test is another thirty.

The follow-up cadence is light. Quarterly rotation pass (1-2 hours). Annual runbook test (30 minutes). Inventory update whenever a new AI tool joins the team (10 minutes per tool). The cost is bounded; the absence of the cost is not.

ShareX / TwitterLinkedInEmail

OPS-074holdingsince 24 May 2026SiblingAM-167RegisterReporting

Spotted an error? See corrections policy →

Related reading

OPS-LEDGER · 48 reviewed