Credential inventory worksheet for AI coding agents

AI coding agents should not receive a pile of inherited credentials and a vague instruction to be careful. Before an agent calls an API, deploys a service, or opens an SSH connection, someone needs a record that says what the credential reaches, who accepts responsibility for it, and how the team will shut it off.

A credential inventory worksheet sounds like administrative work until an agent makes twenty calls while its operator is away from the keyboard. Then it becomes the difference between revoking one known capability and disabling half the engineering organization because nobody can identify the token. I have watched teams discover that their “staging” automation had a production write token only after an automated change landed somewhere it should not have reached.

The inventory must describe authority, not secret strings

A credential inventory worksheet records authority. It does not record the API token, private SSH material, password, recovery code, or an encrypted export of any of them. If a worksheet can authenticate to anything, it has become another secret store with weaker access controls and a much larger audience.

The distinction matters because teams often confuse an identifier with a credential. An API token's last four characters help an operator locate the right entry during rotation. They do not tell you whether it can delete a project. An SSH public-key fingerprint identifies an identity. It does not tell you which Unix account it opens, whether it permits port forwarding, or which hosts trust it.

Use a row for each independently revocable authority. One provider account may need several rows: a read-only production reporting token, a staging deploy token, a break-glass administrator token that agents cannot use, and a webhook signing secret. Combining them in one row makes their different risk and rotation requirements disappear.

The same rule applies to SSH. Do not write “Git and servers” in a single cell because one private key happens to work in both places. A source-control write identity and a host login identity have different consequences. They need separate rows even when the same human created them on the same afternoon.

NIST SP 800-57 Part 1 treats cryptographic key management as a lifecycle problem: generation, distribution, storage, use, replacement, and destruction all need control. That document focuses on cryptographic keys, but its discipline applies directly here. A credential list that stops at “we created a token” is not an inventory. It is a memory aid that fails exactly when staff need reliable records.

Give every credential one accountable owner

Every row needs one named owner who can answer “should this authority still exist?” That owner does not have to run the secret manager or write the agent integration. They do need enough knowledge of the affected system to approve the access and accept the operational consequences.

Avoid owner values such as “platform,” “dev team,” “shared,” or an inactive employee's name. A group can operate a process, but a group name does not tell an incident responder whom to call at 2 a.m. Record a primary owner and, if needed, a backup owner with authority to revoke or replace the credential.

Separate four roles that teams regularly blur:

• The system owner decides whether the access remains appropriate.
• The credential custodian can create, store, revoke, and rotate it.
• The agent operator starts or supervises the agent run.
• The incident contact handles an urgent failure when the first three people are unavailable.

One person may hold several roles in a small team. The worksheet should still name the roles separately. When a token breaks during a release, the custodian may fix storage while the system owner decides whether a temporary replacement deserves the same scope.

For a vendor API, ownership often belongs to the team paying for or operating the account, not the developer who pasted the first token into a local configuration file. For SSH access, ownership usually belongs to the host or application owner, not the person who generated the key pair. This sounds obvious, yet orphaned credentials usually started life as a sensible shortcut taken by a person who later changed teams.

Add a review date that is distinct from a secret rotation date. A token can remain technically valid while its business purpose is gone. Review asks whether the access should exist. Rotation replaces material that may have aged or escaped. Doing one does not complete the other.

Write permitted actions as verbs and targets

“Production access” is not a permission description. It is a warning label that tells an agent operator nothing useful. The worksheet needs verbs, target resources, and boundaries that a reviewer can test.

Write permission entries in this form:

verb + target + boundary + forbidden action

For example:

• GET /v1/projects/acme/builds in staging; no production tenant requests
• POST deployment revisions for service catalog-api; no rollback or deletion
• SSH as deploy on build host group; run approved release command only; no interactive shell
• Create issue comments in repository alpha; no merge, branch deletion, or settings changes

This is more useful than a provider's broad label such as “write.” An agent that can create a deployment revision and an agent that can remove a deployment both hold write permission, but the blast radius is not remotely similar.

Record whether the intended action is read, create, modify, delete, execute, or administrative change. “Execute” deserves special care. An API call that starts a cloud job, rotates a service credential, triggers a payment operation, or runs a remote shell may look harmless in a request log while causing an expensive or irreversible result downstream.

Do not turn the worksheet into a legal document full of fuzzy language. “Use only when appropriate” and “normal deployment work” offer no boundary. A person cannot approve against them, and an engineer cannot build controls from them. If the action depends on context, state the context: a named environment, repository, host group, account, or change type.

The popular shortcut is to grant a general administrator token and rely on the agent's prompt to avoid dangerous calls. It is popular because it gets a prototype moving in minutes. It is wrong because prompts are not access control, and later tool calls can inherit the broad authority without the person who wrote that prompt noticing.

Environments need separate rows and separate consequences

A staging credential and a production credential should never share a row merely because they call the same API. Their owners may match, but their target account, data exposure, approval requirement, and revocation urgency often do not.

Treat environment as more than a label. Record the provider account or tenant, endpoint or host group, data classification, and whether a call can cross an environment boundary. “Prod” is too vague when an organization has several production accounts, regions, or customer partitions.

A workable environment field might read:

production / tenant 4821 / customer account data / endpoint api.example.internal

Do not put an actual internal hostname in a worksheet that many people can read if that hostname itself is sensitive. The point is to name the target with enough precision for the authorized team. Your inventory access policy should match the sensitivity of its operational detail.

Include a separate field for data that an agent can receive in the response. Permission to call an endpoint and permission to view its response are related but not identical risks. A read request might return source code, customer contact information, invoices, access metadata, or a secret embedded in an old configuration value.

This catches a frequent failure pattern. A team creates an agent credential for “read-only diagnostics” in staging. Later, an engineer points the diagnostic client at production during an incident because the command syntax is identical. The credential works because the provider used account-wide scope, and the agent returns customer data in its transcript. The original worksheet row would have exposed the missing boundary if it had named the tenant and response data instead of simply saying “diagnostics read.”

When a provider cannot isolate environments, do not compensate with wishful documentation. Mark the credential as cross-environment, raise its approval level, and decide whether an agent should use it at all. The honest answer is sometimes no.

SSH access needs more detail than API access

SSH credentials deserve their own fields because an SSH connection can carry several kinds of authority at once. The login account, accepted hosts, command restrictions, forwarding permissions, and agent forwarding setting all change what the connection can do.

For each SSH row, record the public-key fingerprint, private material location, login account, host or host group, and the exact intended command. Do not copy the private key into the sheet. A SHA256 fingerprint is sufficient for identification, and operators can derive it locally.

Run this command against the public key file:

ssh-keygen -lf ~/.ssh/id_agent_deploy.pub

A normal result has this shape:

256 SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz0123456789abcd agent-deploy (ED25519)

Store the SHA256: value and the comment only if the comment helps humans identify the role. Comments are not security controls. Anyone can change one when they copy a public key.

For target hosts, inspect authorized_keys restrictions rather than assuming a deploy account is limited because people intend it to be. OpenSSH documents options such as command=, no-port-forwarding, no-agent-forwarding, and no-pty in the sshd manual. Those restrictions can turn an automation identity into a constrained command runner. They cannot repair a credential that logs in as an unrestricted administrator account.

An entry might state: “login deploy, hosts in release group A, forced command /usr/local/bin/release-catalog, no port forwarding, no PTY, no agent forwarding.” If the access needs an interactive shell for emergency work, create a separate human-operated identity. Do not quietly reuse the agent identity because it is already available.

Host verification also belongs in the record. Note how the agent-side integration checks host identity, where known-host entries live, and who updates them after a legitimate host replacement. Disabling host verification to get past a rebuild is an invitation to send a valid credential to the wrong machine.

A usable worksheet has fields that force hard answers

Copy this template into a controlled document, ticket system, or inventory database. Remove any columns your team cannot maintain, but do not remove the fields that establish authority, scope, and recovery.

The agent path column forces a useful question: how does the agent obtain the effect of this credential? “Environment variable in the coding shell” is an answer, but it should make you uncomfortable because the process can print, transmit, or persist it. “Action gateway performs request and returns response” is a different design with a smaller exposure path.

The revocation method field should be executable by someone else. “Ask Sam” is not a method. “Disable token in provider project settings, then revoke active agent session” is a method. Test this instruction when you first add the row, before an incident makes every console page feel unfamiliar.

Avoid a status field that merely says active or inactive. Include last used, last reviewed, and planned retirement. An unused credential is not harmless. It is often the one nobody remembers to revoke after a project ends.

Rotation plans must include replacement and proof

Rotation is complete only when the old credential is disabled and the replacement has completed an intended action through the real agent path. Creating a new token, adding it to storage, and promising to revisit the old token later leaves both identities alive. That doubles the work during an incident.

A rotation plan should state five operational facts:

1. The event that causes rotation, such as scheduled expiry, staff departure, suspected exposure, or scope change.
2. The person who creates the replacement and the person who approves changed authority.
3. The place where the new material is stored without reaching the agent.
4. The narrow test action that proves the replacement works.
5. The exact point when the old material is revoked and the evidence recorded.

Use a narrow test. For an HTTP credential, call a harmless endpoint that requires the intended scope and confirm the expected status and response shape. For SSH, execute the forced deployment status command against the approved host group, rather than testing with a general shell login.

A test record can be as plain as this:

Credential ID: api-catalog-deploy-prod-01
Replacement ID suffix: ...7KQ2
Test: POST /deployments/validate for catalog-api revision 8f3c
Expected: HTTP 200 with validation status accepted
Old credential revoked: provider audit event recorded
Reviewer: production service owner

Do not set rotation schedules that your team cannot meet. A short interval with repeated exceptions trains people to treat the inventory as fiction. Use provider expiry where available, establish event-driven triggers, and schedule a review cadence that matches the risk. Production write access, broad read access to sensitive data, and SSH access to shared hosts deserve more scrutiny than a disposable staging token with no sensitive response data.

If exposure is suspected, revoke first when the service can tolerate it. Teams waste time trying to prove whether a leaked token was copied from a terminal buffer, CI log, prompt transcript, or local history. You rarely need that proof before you stop the credential. Preserve logs, replace the credential, then investigate the path.

Agent approval should follow the consequence of the call

An agent run has a lifecycle that ordinary scripts often lack: a person may start it, leave it working, return later, and discover that it made many external calls. The worksheet should therefore state when human authorization applies, not merely who owns the credential.

Per-session approval fits a contained run with a trusted, identified local agent process and low-to-moderate consequences. It confirms that this process may use the listed authorities while it remains alive. It does not mean every future call deserves a free pass.

Require approval on every use for operations that can publish, deploy, alter production data, reach high-sensitivity responses, or create a new external commitment. The extra click is cheaper than explaining an unintended action to a customer or a finance team. Use a separate credential for actions with a different approval level when the provider supports it.

Approval does not replace scope. A human can approve the wrong thing because the request description was vague, the action arrived during an incident, or the agent made several similar calls in quick succession. Keep permissions narrow first, then use approval to cover the residual risk that scope cannot express.

Sallyport keeps API and SSH credentials in an encrypted vault on the Mac and can require authorization for a new agent process or for each use of a selected credential, while the agent receives results rather than the secrets.

A good worksheet maps each high-consequence row to the audit evidence you expect after use. Record the session identifier or run journal location, call-level activity record, target, timestamp, outcome, and the approving person where applicable. If the evidence cannot tell you which credential was used for which result, the agent integration is too opaque for the authority you granted.

Audit records settle arguments after a bad run

Inventory is preventive work. Audit records answer a different question after an agent behaves unexpectedly: what did it actually attempt, what succeeded, and which authority made it possible? Do not merge these jobs. A carefully maintained worksheet cannot prove that a call happened, and a log cannot prove that a permission was justified.

Build an incident drill around one inventory row. Have an operator locate the owner, revoke the credential, stop any current agent access, identify the last successful call, and verify that the audit trail has not changed. Measure confusion, not elapsed time. If people cannot name the target account or distinguish the old token from the replacement, fix the worksheet fields.

Tamper evidence matters when multiple people can inspect or export logs. A plain append-only database can be altered by an administrator with enough access, then presented as history. A hash-chained log makes unauthorized changes detectable when you verify the chain against the stored sequence. It does not make the original request wise, and it does not prevent an authorized person from making a bad call. Those are separate controls.

Keep the audit retention decision alongside the inventory record, especially when responses may contain sensitive output. An activity record should preserve enough context to investigate without casually retaining full customer payloads forever. Store request metadata and result status where possible; reserve full response capture for cases where it is truly necessary and allowed.

The first credential row you should complete is the one an agent can use to make a production change today. Name its target precisely, make the permitted verb concrete, write the revoke instruction so another person can follow it, and test the replacement path. If that row contains guesses, the rest of the inventory is decoration.