4/4: A Practical Security Playbook for Teams Building With AI

The coding agent has a useful job: investigate a CSV import bug, run tests, and open a pull request. It does not need to publish a release. Somehow, after several convenient integrations, it can do both.

That is the design problem I want to fix.

Part 1 examined the evidence. Part 2 introduced a hypothetical SaaS team whose coding agent encounters an attacker-controlled issue. Part 3 followed a CSV parser fix through review and deployment. This final part gives that same workflow a permission model, a shutdown procedure, and a first month of work.

Define the job before granting access

Our fictional application imports customer CSV files through a background worker. The assistant reads issues and source code, reproduces failures in a disposable workspace, and proposes patches. CI builds the approved change; a release operator authorizes deployment.

The unsafe starting point is familiar: the workspace inherits a developer’s broad GitHub credential, can reach arbitrary network destinations, and has access to more host files than the task needs. A repository instruction or package installation now sits close to unrelated authority.

The agent-specific concern is that external text can influence the next tool request. The process-security concern is that untrusted code can run in the same workspace. Both deserve controls. A better system prompt addresses neither credential inheritance nor a malicious process reading an accessible file.

OWASP’s Agentic Applications Top 10 is useful for naming these boundaries. For the actual design review, draw the path: issue and attachment → analysis workspace → proposed change → CI artifact → release approval → running worker. Put an identity and owner beside each transition.

Give each stage only the authority it needs

For this team, I would start with three roles. The analysis workspace can read the selected repository and run local tests. A narrowly scoped integration can open a branch or pull request in that repository. A separate release identity can deploy an approved artifact to the named environment.

Those roles need not imply three new products. They describe permissions that the existing tools must enforce. Some platforms separate them cleanly; others may require keeping a step manual until a safe boundary is available.

The proposal identity must not be able to merge its own change, bypass required review, alter repository protections, or obtain the release identity. A branch-writing credential deserves scrutiny too: a workflow triggered by that branch must not expose privileged secrets to untrusted code.

OWASP’s authorization guidance supports enforcing least privilege at the service boundary. My test for this design is concrete: the integration can open the intended pull request, but harmless attempts to write to another repository or authorize a release fail. Record the denied requests as well as the successful one.

Keep suspicious input away from useful secrets

The issue attachment is necessary for reproduction. Production cloud credentials are not. Mount the selected workspace, supply dummy test secrets, and restrict reachable services to the approved task. Review inherited environment variables, credential helpers, SSH-agent access, and host mounts before calling the environment isolated.

Suppose the issue claims a diagnostic upload is required. The model may reject that instruction, or it may request the upload. In this design, an unapproved destination is denied either way. A model mistake remains observable without automatically becoming a disclosure.

Package installation is a separate path. A malicious install script may use network and filesystem access directly, without asking the agent’s tool interface. Tool-level approval is therefore insufficient if the underlying process retains unrestricted access.

OWASP’s Secure Coding with AI guidance is a useful reference for reviewing this environment. The acceptance check here is a disposable job that completes the legitimate tests while failing to read an out-of-scope dummy secret or contact an unapproved test destination. A network restriction can also break dependency installation; solve that explicitly with an approved dependency source rather than silently removing the boundary.

Approve the exact release

“Approve the agent’s plan” is too loose for deployment. The reviewer needs the proposed diff, test evidence, artifact identity, destination environment, and rollback procedure. Approval should apply to that concrete change and target. If those change, the earlier approval should not authorize the new action.

This addresses a particular agent risk: a system that revises its plan after an error can produce a different action from the one a person reviewed. The execution service must check what is actually requested, even when the explanation still sounds familiar.

OWASP’s AI Agent Security guidance describes scoped tools and approval controls for consequential actions. For our team, the test is to approve a disposable deployment, then change its target or artifact reference. Execution should require fresh authorization. A mismatched action must not inherit the old approval.

The reviewer still has work to do. A long generated explanation can bury the important detail. Put the actual environment and artifact beside the approval control, with links to the evidence that supports the change.

Protect the workflow that produces the artifact

The CSV patch may be safe while a release-workflow edit in the same pull request is not. Review those separately. A parser change should not quietly acquire permission to change publication credentials or bypass release review.

npm trusted publishing is an example of using workload identity instead of a long-lived publishing token. It reduces a credential problem; the approved workflow still needs protection. A compromised workflow can produce an artifact with a legitimate-looking origin.

For this service, record the approved commit, build run, artifact identity, and deployed worker version. The platform owner should demonstrate that a pull request from the proposal identity cannot alter privileged release controls without independent review. The release owner should show which artifact actually reached the worker.

This is established supply-chain security applied to an agent workflow. The practical change is that a system reading untrusted content can now propose edits to the very workflow that would authorize its future actions. That relationship deserves an explicit review.

Make revocation stop work, not just hide a key

LiteLLM’s corrected 23 October postmortem traces its release compromise to an exposed administrative key that had not been revoked, followed by access to an overly privileged GitHub token. Removing the exposed file did not remove the authority.

For our fictional integration, name the person who can revoke the proposal identity, the release identity, and any derived session. Prefer short-lived credentials where the platform supports them. Keep the credentials out of model context and routine logs.

Then run a controlled exercise: revoke a test identity, verify its old credential fails, and inspect queued and running jobs. Closing the chat window may leave a worker executing elsewhere. The stop procedure needs to cancel or constrain that work too.

The incident owner’s evidence should show the last permitted side effect and whether any operation continued after revocation. Where cancellation is not immediate, document that limit and restrict the queued work accordingly. “We have a stop button” is a claim to test.

Rehearse a failed fix

An agent can cause damage without an attacker. In our CSV example, a patch might reject legitimate files, a retry might duplicate an import, or a deployment might reach the web service while missing the worker.

Use a disposable environment to test those paths. Give import jobs stable identifiers if the application supports deduplication. Check how partial work is recovered. Deploy a deliberately failing test artifact, exercise rollback, and verify the restored worker can process approved fixtures. Keep recovery access outside the agent’s everyday identity.

The model can help draft an incident timeline. Restoration still needs evidence from the service. A generated “rollback succeeded” message should point to the deployment and health checks that establish it.

A first month with owners and evidence

This is a proposed sequence for one workflow, not a promise that a month makes the organization secure. Resolve urgent exposures as soon as they are identified.

• Week 1 — engineering lead and platform owner: map the CSV workflow, identities, mounts, destinations, and release path. Deliver an access diagram and a ranked list of excessive permissions. Assign an owner to each gap.
• Week 2 — platform and repository owners: remove inherited credentials, scope the proposal identity, and protect privileged workflows. Keep successful-task and denied-access results from a disposable test run.
• Week 3 — service and incident owners: exercise the misleading issue, altered deployment target, revoked credential, repeated job, and failed rollout. Record actual side effects, cancellation limits, and recovery results.
• Week 4 — engineering lead and reviewers: compare correct findings, missed cases, review effort, total time to verified deployment, and cost with the existing workflow. Decide whether to expand, revise, or keep the pilot narrow.

NIST SP 800-218A supplements secure-development practices for generative AI and foundation-model development. Use the portions relevant to the team’s work alongside its existing lifecycle; this proposed month is not a complete implementation or a compliance claim.

The decision at the end of the pilot

For this team, I would expand access only after answering three questions with records: did the assistant produce useful, independently verified work; did the permission boundaries hold when it requested the wrong action; and could the team stop and recover the workflow?

A faster reproduction with an extra hour of patch review may still be useful. A faster merged patch that leaves the old worker running has not closed the exposure. Report the whole outcome.

The series began with a worldwide question about attackers and defenders. The engineering decision ends closer to home: this agent can investigate an import bug and propose a fix; it cannot quietly turn an instruction in an issue into release authority. We have tests and records supporting that boundary, and a procedure for when something goes wrong.

That is a specific security improvement a team can build on.