A solo engineer's WISP for an army of AI agents

A coding agent's usefulness depends partly on what it can reach: repositories, files, tools, services and the credentials used to access them. That reach is part of the system's security design.

A Written Information Security Program, or WISP, records what you protect, the risks you are managing, the safeguards you implement, and how you test, maintain and recover those safeguards. For a solo engineer, it can be a small set of maintained documents and controls with one accountable owner. Its scope reaches beyond the application code into the development environment and the services that support delivery.

CTO to Human: knowing what you have entrusted to the system

When I add agents, I want to understand what each one can read, change and cause to happen. I also want to know how that access ends and what I will do if it is abused.

A written program gives those decisions continuity. It makes an account review, a credential change or a recovery exercise something I can revisit and evaluate. It also gives me a concrete basis for discussing security with a collaborator or customer, while keeping operationally sensitive details private.

WISP terminology also appears in regulatory requirements. For example, the FTC Safeguards Rule guidance describes a written security program for covered financial institutions. Applicability depends on activities, data and jurisdiction. The program below is an engineering approach to tailoring controls; copying it does not establish that a particular business has met its obligations.

Engineer to Engineer: define the program's scope

Start with the systems that could expose information or change what a user runs. Include source hosting, cloud accounts, package registries, DNS and email, signing services, CI, development machines, backups and third-party tools. For an agent, include its model provider, extensions, connectors and execution environment.

My public security program uses this approach for the accounts and infrastructure supporting KofTwentyTwo software. It states requirements publicly and keeps inventories, recovery details and secret locations private. That separation is useful for a solo maintainer: other people can inspect the expectations without receiving a map of the operational environment.

An illustrative structure is:

public-standards/
  policies/security-program.md
  policies/ai-assisted-development.md
  policies/sdlc.md
  policies/exceptions.md

private-security-records/
  asset-and-data-inventory
  access-and-provider-reviews
  risk-register
  credential-lifecycle-records
  incident-and-recovery-runbooks
  verification-and-exercise-results

These are logical records, not a requirement to put everything in Git. Choose storage appropriate to their sensitivity. Store secret values and recovery codes in a protected credential system, separate from the program's documentation.

Inventory assets, data and identities together

An asset inventory should identify the asset, purpose, owner, environment, data involved, access paths and dependencies. A data inventory should describe classification, collection, storage, transmission, retention and disposal. An access inventory should identify the human or workload identity, capabilities, scope, credential lifecycle and revocation method.

Consider an illustrative agent implementing an export feature:

Trace the path data takes. A read-only connector may still return sensitive records into the agent's context, logs or model request. Filesystem permissions and provider data-handling decisions address different parts of that path.

Document which data may enter prompts and which must remain outside the agent environment. Verify the behavior of actual tools and settings. A sentence in the WISP cannot remove a connector's access or prevent a tool from logging its response.

Turn risks into controls with owners and evidence

A risk record should connect a scenario to an asset and consequence. Add likelihood and impact reasoning, the chosen treatment, implementation status, owner and next review trigger. Avoid a score without an explanation of what could happen.

For example, an agent might encounter hostile instructions in a downloaded file, then attempt to use a credential available to its process. The safeguards span several layers: treating retrieved content as untrusted data, withholding unnecessary credentials, limiting tools and network access, and reviewing operations that cross a trust boundary.

An illustrative record might be:

The record specifies a design to implement. It does not make every harness enforce it. A model's refusal can be useful behavior, but the publishing service and execution environment need their own access controls.

Make agent permissions a lifecycle

Assign capabilities by task: what may be read, which workspace may be changed, which tools may run, which endpoints may be called, and which actions require a human decision. Separate development, verification and production identities. Scope access to the repository or service involved and choose expiry appropriate to the work.

An agent drafting code usually needs source and synthetic tests. An agent evaluating a deployment may need bounded observations from production. An agent carrying out an authorized publication needs an identity limited to that operation. Combining those capabilities in every session makes the security boundary larger than the task requires.

Permission checks should occur when the operation runs. A previously valid token can expire or be revoked, and a reviewed artifact can change. Revalidate identity, target and artifact at the point of mutation. Record enough to investigate the action without recording credentials or sensitive payloads indiscriminately.

My AI-assisted development policy makes human accountability, least privilege, untrusted input and data handling explicit. A project needs to translate those expectations into the capabilities its actual agent tools expose, and record departures rather than silently treating access as harmless.

Design credentials and account recovery before an incident

Use multi-factor authentication and prefer phishing-resistant factors where supported. Keep ordinary agent processes away from signing identities, credential stores and broad administrative tokens. A narrowly scoped credential used by a trusted operation should be injected through the intended secure mechanism, used for that operation and excluded from prompts, logs, command arguments and artifacts.

For each credential, record its purpose, scope, owner, expiry or rotation policy, revocation path and consuming service. This record holds references and metadata; the credential value belongs in the credential store. Where a service supports workload federation or another suitable short-lived identity, evaluate that route to reduce dependence on long-lived secrets.

Recovery access needs its own design. Decide how to regain control if the primary device or login method is lost. Protect recovery codes and test the recovery process through the provider's supported procedures. Backing up source does little for an account takeover if recovery depends on the compromised email account.

Protect the workstation, pipeline and supplier paths

Include device encryption, supported operating systems, updates, screen locking and the permissions of installed tools. Treat agent plugins and connectors as part of the toolchain: identify their source, version, capabilities and update process. A connector that can execute code or read credentials changes the threat model.

In CI, examine where untrusted code executes and which secrets or write permissions are reachable. Keep contribution verification separate from privileged release operations. Pin dependencies and review changes to the build definition. The CI standard gives concrete examples of these boundaries.

Review providers as well as packages. Identify the data a service receives, administrative access, retention and deletion behavior, account recovery and what happens when the service is unavailable. For model providers, review the applicable service configuration and terms instead of inferring data handling from the product's brand name.

Define detection, response and recovery as executable work

Choose signals that can reveal the risks you identified: unexpected privileged requests, account changes, unexplained releases or failed authentication patterns. Define where those signals go, who examines them and how long records are kept. Collect enough to investigate while avoiding unnecessary sensitive data in the logs themselves.

An incident runbook should identify containment decisions, evidence sources, recovery steps and communication responsibilities. For an exposed credential, deleting the text from a repo is insufficient. Revoke or disable the affected access, determine the reachable systems and review their activity, then replace credentials and recover from a trusted state.

Preserve evidence in a protected location while containing active exposure. Record timestamps, affected identities, actions taken and the known limits of the investigation. Plan how to notify users, partners or authorities when applicable requirements call for it. The incident workflow should make the decision owner and escalation path clear.

My security program's incident-response section is a public example. Its timing commitments belong to that program; choose and maintain your own commitments based on the product, obligations and ability to respond.

For recovery, specify a recovery point objective (how much recent data loss you can tolerate) and a recovery time objective (how long the service can be unavailable). Use those decisions to choose backup cadence, isolation and retention. Include the data, configuration and keys required to make a restoration useful.

A successful backup job establishes that a job ran. A restore exercise establishes whether the saved material can rebuild the service and recover the required data. Test in an isolated environment, check the application behavior and measure the result against the recovery objectives. Record gaps and remediate them.

Connect the WISP to the SDLC and review its operation

The SDLC governs how a change is designed, reviewed, released and maintained. The WISP supplies security decisions that the change must respect. In the export example, the WISP defines protected data and access expectations; the SDLC carries those expectations through design, denial tests and release verification.

The SDLC companion article develops that workflow. Treat changes to connectors, identities, providers and deployment permissions as triggers to review the security program, even when application code barely changes.

For a starting program, schedule recurring access reviews, dependency and vulnerability triage, backup checks and a recovery or incident exercise. Choose intervals against the risk, record them, and verify that you can sustain them. Review after incidents and material changes. Exceptions need an owner, affected scope, mitigation and a review date.

I would establish the program by inventorying one product, tracing its data paths and checking the most consequential capabilities. Exercise a denied agent operation, a credential revocation and a restore. Use the results to improve the written program and the actual controls together.

An army of agents makes this connection valuable: each contributor needs a bounded environment, and the accountable engineer needs evidence that the boundaries work. A WISP turns that responsibility into something you can inspect, maintain and recover when the assumptions change.