Contractor-managed AI agents: end production access cleanly

A contractor can do excellent work with an AI coding agent and still leave your production environment in worse shape than they found it. The failure usually does not start with a malicious prompt. It starts when everybody assumes somebody else owns the agent process, the approvals, and the cleanup.

Treat a contractor-run agent as a temporary production operator. Give it an accountable internal sponsor, a recognizable process identity, a narrow authority path, and a removal procedure that someone has rehearsed. If you cannot name the employee who can stop it today, you have not delegated work. You have created an orphan.

A contractor's identity cannot own a production agent

The company that owns the production system must own the agent's authority, even when a contractor launches and supervises the process. A contractor's employment relationship, personal account, laptop, and calendar invitation all end on terms outside your direct control. Production access cannot depend on any of them.

Teams often confuse two questions:

• Who operates the agent during this engagement?
• Who remains accountable for every capability the agent receives?

The contractor may answer the first question. An internal employee must answer the second. That employee needs enough authority to pause the work, change its scope, inspect records, and end access without waiting for the contractor to respond.

I have seen this go wrong in a very ordinary way. A contractor receives an invitation to a source repository and a production API token because they need to diagnose an issue. They use an agent from their own machine to inspect code, query the API, and prepare a fix. The contract ends, the contractor's repository account is disabled, and everyone feels finished. Weeks later, an automated terminal profile still has the token. The agent's old working directory still contains instructions that tell it how to use the token. The company has removed a person from one system, not removed an operational path from production.

Do not make the contractor's user account the durable identity for agent work. Create a company-owned engagement record and bind access to that record. The record should identify the internal sponsor, the technical custodian, the operator, the approved environments, the process identity, and the end condition. A person can change jobs or disappear into a weekend. A record can still tell the next on-call engineer what exists and how to turn it off.

This is not bureaucracy for its own sake. It prevents the most expensive form of ambiguity: an incident where the team cannot tell whether a request came from an approved agent, an old contractor setup, or an attacker reusing forgotten access.

Put one employee in charge of the decision to delegate

Every contractor engagement needs a sponsor who owns the decision to let an agent act, not merely the decision to hire the contractor. The sponsor is usually the engineering manager, service owner, or incident commander with authority over the affected production area.

That sponsor should answer four concrete questions before the agent receives production authority. What job is the agent doing? Which environment can it reach? What actions are within the job? When does the permission stop?

Avoid vague scopes such as "help maintain the service" or "assist with deployment." Those phrases become dangerous when an agent can interpret them through tools. Write work in observable terms instead: inspect error responses from this service, open a pull request, run this approved diagnostic command, or submit a change request for a named endpoint.

The sponsor does not need to sit beside the contractor all day. They do need to own the boundaries. If a contractor says the work now requires a database write, a new infrastructure role, or access to another service, that is a new delegation decision. Do not let a prior approval quietly stretch to fit a new request.

NIST Special Publication 800-207 makes a useful point in its zero trust guidance: systems should not grant implicit trust simply because an actor sits on a particular network or previously accessed a resource. Apply that logic to agent work. A contractor being in your chat channel, on your VPN, or previously approved for a read operation does not authorize a different process to make a production write.

This is where teams often choose the wrong simplification. They give the contractor broad standing access because repeated approvals feel slow. The approvals feel slow because the work was not defined well enough. Fix the work boundary first. Broad standing access converts a planning problem into an incident response problem.

Give the sponsor an explicit replacement. If they leave, transfer the engagement record and reapprove the authority under the new sponsor. A process with no current sponsor should lose access automatically or be disabled manually at once. There is no legitimate reason for an unattended contractor engagement to keep production authority.

Process provenance must be part of every approval

Approving a person is different from approving a process. This distinction is routinely blurred, and it creates approvals that cover more software than the reviewer intended.

A human identity tells you who authenticated. A process identity tells you what executable asked for an action, where it ran, and whether it matches the process you expected. When an AI agent works through shells, extensions, MCP servers, background helpers, and scripts, the process is the thing that actually reaches the credential path.

Ask for evidence that a new agent process is the approved process. On macOS, code signing authority gives a reviewer a useful starting point. It can identify the signing authority presented by an executable. It cannot establish that a production request belongs to this contractor engagement, nor can it decide whether the requested action is sensible. Use it as process evidence, not as a blanket permission slip.

A practical approval card should show more than the contractor's display name. It should identify the process or launcher, its code signing authority when available, the active engagement, the target environment, and the requested capability. If the reviewer cannot distinguish a known agent process from a copied script, the approval is too weak.

This catches a common failure. A contractor starts an approved coding agent in one terminal. Later, a shell script or another agent process inherits environment variables, reads a local configuration file, and makes the same request through the same credential. A person-only approval cannot tell that these are different callers. The second process may be harmless, but nobody has established that.

The right response is not to demand impossible certainty from reviewers. It is to reduce the amount a single approval covers. Bind approvals to a session or process run, identify that run clearly, and expire the approval when the run exits. A new process should introduce itself again.

Keep a local record of the process command, working directory, launch time, sponsor, and expected exit condition. You do not need to collect every private prompt or file the contractor reads. You need enough operational evidence to answer a basic incident question: which approved process performed this action, under whose authority, and was it still inside its assigned engagement?

Approval ownership must follow blast radius

The person who approves an agent action should match the consequence of that action. A contractor can approve routine actions within a delegated, narrow task. They should not silently become the final authority for actions that can alter production data, permissions, customer communications, or infrastructure.

Split approval into two layers. The sponsor authorizes the category of work and its duration. The action approver authorizes a particular operation when its impact deserves a human decision. In a small team, one employee may fill both roles. Keep the responsibilities separate in the record anyway, because they answer different questions later.

Use a simple ownership model:

• The sponsor owns the purpose, scope, and expiration of the engagement.
• The contractor operator owns the quality of the task and requests actions within scope.
• The action approver owns the decision to allow a sensitive call.
• The technical custodian owns the credential path and the shutdown procedure.
• Security or operations verifies that revocation completed.

Do not install an approval ritual for every harmless read merely to claim human control. Reviewers will click through it, then miss the request that deserves attention. Put friction where the action changes state, expands authority, reveals restricted data, or reaches a new production target.

Per-call approval works best for operations that are easy to recognize and hard to undo: a write to a customer record, a production deployment, an SSH command with administrative effect, or a request that changes permissions. Session approval works for bounded investigative work where the process needs to make several related reads. The record should say which one applies before work begins.

The approval screen must also state the target. "Allow agent to use API" tells the reviewer almost nothing. "Allow this approved process to send a POST request to the production billing endpoint" gives them a decision they can own. A good reviewer can still reject it, ask for a change request, or require the contractor to use staging.

Approval fatigue is a design failure, not a reason to abandon approval. If the queue becomes noise, narrow the tools, group safe operations into a short session, or move the investigation to a nonproduction environment. Do not solve it by making production authority permanent.

Keep credentials out of the agent's context

An agent should request an action, not hold the secret that authorizes it. This is the line that makes offboarding feasible.

If a contractor's agent receives a plaintext API token, an SSH private key, or a copied secret in a configuration file, you have already lost control of where that credential can travel. The token can land in terminal history, agent memory, logs, temporary files, a code patch, or a prompt sent to another service. Rotation may clean up the credential, but it does not reconstruct where it went.

Use an action gateway that retains credentials on the company-controlled side and executes approved HTTP or SSH actions on the agent's behalf. The agent receives the result, not the secret. This does not make an unsafe action safe. It gives the team a place to apply approval, record the call, and revoke the authority without hunting through a contractor's filesystem.

Sallyport follows this model for HTTP API calls and SSH commands: secrets stay in its encrypted vault and the agent asks for actions through an MCP connection instead of receiving the credentials. The useful property here is separation, not magic. A compromised or careless agent can still request harmful actions within its granted scope, which is why ownership and approvals remain necessary.

Treat each credential path as an inventory item. Record the credential's owner, target, permitted action type, engagement reference, and shutdown method. Do not settle for a note saying "production token used by contractor." That note tells an incident responder nothing about where the token lives, whether it was copied, or which path must be disabled.

SSH deserves extra care because teams often assume a host login is temporary if the contractor is temporary. Check for authorized keys, certificates, local agent forwarding, jump-host access, shell profiles, scheduled jobs, and remote copies of deployment scripts. Removing one public key does not revoke a private key that can still reach another trusted hop.

The same rule applies to HTTP credentials. Remove or disable the action path, then verify the target rejects a new request. Do not call it done because an access management screen shows a user disabled. The action gateway, service account, API credential, and network route may have separate lifecycles.

Design revocation before you grant access

A team should be able to revoke a contractor-run agent without asking the contractor to cooperate. If the procedure requires their laptop, their password manager, or their memory, it is not a revocation procedure.

Write the shutdown path before the first production action. It should cover the agent process, approval session, credential route, source and infrastructure access, scheduled work, and audit preservation. Every item needs a named operator and a way to verify completion.

The distinction between disable and revoke matters. Disabling stops future use of a particular account or credential. Revoking ends the active authority relationship and removes paths that can restore it. A contractor's account may be disabled while an already running process retains a live session. A token may be revoked while an SSH connection remains open. Handle both states.

Use this sequence when an engagement ends or must stop immediately:

1. Block new agent actions at the credential gateway or authorization point, then revoke active sessions tied to the engagement.
2. Stop the known local and remote agent processes, including terminal multiplexers, launch agents, CI jobs, and scheduled tasks.
3. Disable or rotate company credentials assigned to the engagement, and remove repository, cloud, VPN, bastion, and ticketing access.
4. Search the engagement inventory for copied configuration, generated scripts, deploy keys, and temporary service accounts, then remove them.
5. Verify rejection by attempting a harmless authorized-path check and preserve the action records before closing the engagement.

Order matters. If you start by deleting records or disabling a contractor account, you may lose the information needed to find active sessions. Stop action paths first, preserve evidence, and then clean up access.

Do not claim success because every checkbox has an owner. Test the procedure during the engagement. Ask the custodian to revoke a nonproduction session while the contractor is present. Confirm that the agent cannot make another call, that the contractor understands what stopped, and that the activity record shows the denial. The first time your team discovers a missing shutdown path should not be during a security incident or a contract dispute.

A short engagement record exposes missing decisions

A small, reviewable record catches more real problems than a long access policy nobody reads. Store it with the work ticket or a controlled operations repository, not inside a private chat thread.

This example is deliberately plain. Replace the placeholder values with your own identifiers, but do not omit fields because the engagement seems temporary.

engagement: contractor-search-repair-2025-04
sponsor: employee-ops-owner
technical_custodian: employee-platform-owner
contractor_operator: external-developer
purpose: diagnose production search indexing failures
agent_process:
  approved_launcher: signed-local-agent-process
  allowed_workstation: managed-mac-asset-184
  expires_at: 2025-04-30T17:00:00Z
scope:
  environments: [staging, production-read]
  permitted_actions:
    - GET search-service health endpoint
    - GET indexing queue depth endpoint
  prohibited_actions:
    - production writes
    - credential administration
approval:
  session_owner: employee-ops-owner
  per_call_owner: employee-platform-owner
credential_routes:
  - search-api-read-route
  - bastion-diagnostic-route
revocation_owner: employee-platform-owner
verification_owner: employee-security-owner

The record separates things that people commonly collapse into one label. contractor_operator is not sponsor. session_owner is not necessarily per_call_owner. revocation_owner is not the person who decided the work was needed. That separation prevents the contractor from effectively approving their own expansion of authority, and it prevents an absent manager from becoming the only person who can stop access.

The permitted_actions field should use verbs and targets. "Read-only" is too loose when a service has endpoints that trigger exports, reveal personal data, or consume capacity. "Production-read" should also be interpreted carefully. A read can still expose regulated data or operational details that make an attack easier.

Set an expiration even if the contract has no exact end date. Extend it through a new decision when work continues. An explicit renewal forces the sponsor to check whether the work still needs production access and whether the original process is still the process in use.

Audit records must answer operational questions

An audit trail for agent work must answer who authorized the action, which process requested it, what target it reached, whether it succeeded, and when someone revoked the authority. A chat transcript cannot answer all of that reliably.

Keep two views when possible. One view follows the agent run or session, so an investigator can see the authorization lifecycle and stop a live run. The other view follows individual actions, so an operator can inspect a specific API call or SSH command. Tie both views to the same underlying event record rather than maintaining separate stories by hand.

Protect the audit log from the process it records. A process that can change its own history can hide the most relevant evidence. Append-only storage, restricted write access, and cryptographic chaining all help, but each mechanism has a job. A chain can reveal that records were altered or removed. It cannot tell you whether the original request was a good idea.

Sallyport keeps session and activity journals projected from an encrypted, hash-chained audit log. Its sp audit verify command can verify the chain offline over ciphertext, which is useful when the machine holding the vault is locked or an investigator should not read the secrets themselves.

For every engagement, decide who reviews records and when. A sensitive production write may require a review before the contractor continues. A short diagnostic task may only need review at closure. The team should still know how to locate the events during an incident.

Also preserve denials. A denied action can reveal that the agent tried to exceed its scope, that a contractor misunderstood the task, or that a stale process is still alive after offboarding. If you only keep successful calls, you throw away the evidence that often explains the next incident.

Contract language should match the access design

A contract cannot revoke an API token, but it can remove the ambiguity that leads teams to leave access behind. Write operational obligations in language that corresponds to the actual controls your team uses.

State that the company owns credentials, process registrations, audit records, and any access configuration created for the engagement. State that the contractor must use approved company-controlled paths for production actions and must not copy credentials into local files, prompts, repositories, or third-party services. If the work needs an exception, require written approval from the sponsor before the exception occurs.

Include a return and deletion obligation for work materials, but do not rely on an attestation as your only control. Contractors can act in good faith and still miss a shell history file, a cached environment variable, or a backup. Technical revocation handles what you can control. Contract terms cover the obligations that remain outside your systems.

Define the end of the engagement operationally: the sponsor closes the work, the custodian disables action paths, the verification owner confirms the denial test, and the team retains the audit record under its normal retention rules. If the contractor needs later support access, open a new engagement instead of resurrecting the old one.

Avoid clauses that say the contractor is "responsible for security" without naming decisions and controls. That wording sounds firm but leaves the hard questions unanswered when somebody asks for a production change at 6 p.m. Write who can approve the change, who performs it, and who can halt it.

The first document to prepare is not a broad AI policy. It is the engagement record for the next contractor who needs an agent near production. Fill it in with the sponsor and custodian in the same room. Any blank field points directly to work your team still needs to do before granting access.