Approver for AI agent actions: ownership by shift

An approver for AI agent actions should be the person accountable for the affected system during the relevant shift. It should not default to the developer who happened to open the coding session. Those are often different people, and treating them as interchangeable produces approvals that look legitimate until a production call goes wrong.

I have watched this fail in the ordinary way, not through dramatic sabotage. A developer asks an agent to diagnose a build issue. The agent finds a related production endpoint, requests a write to adjust a setting, and the developer approves because the prompt appeared in their terminal. The service owner discovers the change later, during their on-call shift, with no context and no useful answer to "who accepted this risk?"

Ownership has to follow the system, its current state, and the person carrying the pager. A useful approval design makes that fact visible before the action runs.

The session starter rarely owns the consequence

The person who starts an agent owns the request they typed. They do not automatically own the database, vendor account, deployment target, or customer data that the agent may touch.

That distinction sounds fussy until a coding task crosses a boundary. A repository can contain deployment scripts, operational credentials, migration tools, and links to systems maintained by several teams. An agent can follow those paths faster than a human who knows the repository well. The launcher's familiarity with a codebase does not grant them operational authority over every reachable system.

Separate three roles in your design:

• The requester asks the agent to investigate, change, or deploy something.
• The system owner accepts the operational risk for the target service during their assigned shift.
• The executor holds the capability to perform the call or command after authorization.

One person can fill all three roles in a small team. That is fine when it is explicit. The mistake is silently collapsing them because the agent runs on one developer's machine.

This also clears up a frequent argument: "The developer is responsible for their agent." They are responsible for directing it and for the code they submit. The on-call owner is responsible for service behavior, data handling, rollback decisions, and customer impact. A permission prompt should land with the person who can make that second decision.

NIST SP 800-53 Rev. 5, control AC-2, calls for designated account managers and account management procedures. It does not prescribe an agent approval screen, but the underlying discipline applies cleanly: assign responsibility for access rather than treating access as an ambient property of whoever is currently logged in. For agent actions, the relevant account manager is often the current service owner, not the workstation user.

Service ownership must include a shift boundary

A durable ownership record names both the service and the person responsible now. A static team name is not enough at 02:00, during leave, or in the middle of an incident.

For every system an agent can affect, keep a small roster with four fields: the primary owning team, the active shift owner, a backup, and an escalation route. The roster may live in an on-call system, a repository, or an internal directory. Its location matters less than whether people keep it current and whether an approval system can consult it.

Use the service boundary that operators use when they receive an alert. "Payments API production" is a useful target. "Backend" is not. A single broad team label hides different databases, vendors, data classifications, and rollback procedures.

A minimal record can look like this:

service: billing-api-production
active_owner: billing-oncall
backup_owner: payments-duty-manager
escalation: incident-commander
approval_rules:
  read_customer_records: session
  change_remote_configuration: per_call
  production_database_write: per_call
  create_vendor_credentials: prohibited

This is not a policy language for an agent to interpret. It is a human-owned declaration of who can make decisions and how much scrutiny an action needs. The failure it prevents is familiar: an approval request reaches a general engineering channel, someone recognizes the repository name, and nobody recognizes the production system behind it.

Treat the roster as operational data. A team reorganization, a new managed service, or an on-call rotation change can invalidate it. If your approval routing depends on a spreadsheet that only one manager can edit, you have created a quiet single point of failure.

Action risk belongs to the target, not the verb

"Read" and "write" are too crude to assign approval rights. A read against a public status endpoint differs from a read that returns a customer export, a deployment secret, or a complete list of internal hosts. A write that creates a temporary branch differs from a write that changes a payment provider setting.

Classify actions by the consequence of a successful result. Start with the target system and data, then consider reversibility and blast radius. This gives owners a meaningful basis for choosing approval scope.

A practical set of categories is small:

• Routine operational reads return no sensitive material and do not alter state.
• Scoped changes affect one known resource and have a documented rollback.
• High-impact changes affect production configuration, customer data, access, or external commitments.
• Prohibited actions should never run through an autonomous agent channel.

Do not label an action low risk because the HTTP method is GET. I have seen diagnostic endpoints return environment variables, signed links, and operational details that should never have reached a coding agent. The owner who understands the endpoint must classify it.

Likewise, do not demand a manual confirmation for every harmless status check. That design creates approval fatigue. People eventually click through a routine prompt because they expect it to be routine, then approve the one call that was not. Reserve per-call approval for credentials and targets where each invocation deserves a deliberate decision.

The approval text must identify the concrete target. "Agent requests API access" tells an owner nothing. "Agent process requests PATCH to production billing configuration using the billing-admin credential" gives them enough information to stop and ask the right questions.

A bounded session is different from a blank check

A session approval should cover one identifiable agent process for a defined period, not every future process launched from the same repository or user account.

This distinction matters when a terminal stays open across a handoff, when a developer restarts an agent after changing its instructions, or when a malicious local process imitates a familiar command. Approval tied only to a user identity is too broad. Approval tied to a process without a clear identity is easy to misread.

Good session approval answers five things in plain language: which process requested it, who signed or supplied that process, which action channel it may use, which service scope applies, and when its permission ends. The session should end when the process exits. A new process earns a new decision.

Sallyport's per-session authorization follows this pattern by showing the requesting process's code-signing authority and approving that run only until it exits. That is a better default than trusting a terminal tab because a terminal tab is not an identity boundary.

Keep high-impact credentials outside the session grant. A production database write or a vendor access change should prompt the current owner on every use, even if they approved the agent's diagnostic session ten minutes earlier. The first approval says, "This process may work on this system." The later approval says, "I accept this exact irreversible or sensitive action." Those are different judgments.

Avoid permanent approvals labeled "developer tools." They become invisible entitlement pools. They also make incident review miserable because nobody can tell whether the approving person expected this particular agent to use that capability.

Shift handoff must transfer authority, not just information

A handoff message that says "Alex is on call now" does not fix agent approvals if yesterday's sessions and approvals continue to work under the previous owner.

The outgoing owner should hand over active agent work in the same way they hand over a partially mitigated alert. Record the process identity, target services, requested scope, expiration, and any actions waiting for confirmation. The incoming owner must be able to see that record before accepting the shift.

Use this handoff sequence:

1. End or revoke sessions that the outgoing owner no longer wants to sponsor.
2. List active sessions that must continue, with their target and expiry.
3. Transfer the service roster to the incoming owner and confirm their notification path.
4. Require the incoming owner to make fresh decisions for new high-impact calls.

Do not hand a broad approval from one shift to another merely because the engineering task has not finished. The incoming person may have different incident context, maintenance constraints, or knowledge of an ongoing vendor problem. Their approval must be their own.

The awkward case is an action already in progress at handoff. If it is reversible and observable, let it finish under its recorded authorization and make the result visible to the new owner. If it is destructive, externally visible, or waiting for a second call, stop at the boundary and ask again. A few minutes of delay costs less than making a stranger inherit an unreviewed production change.

Incidents need narrower authority, not looser memory

During an incident, teams understandably want speed. They often respond by granting a broad, long-lived agent permission to "help fix production." That permission will outlast the urgency and eventually become an unexplained hole.

Assign approval to the incident commander or the person formally delegated by that commander for the affected system. The service's normal on-call owner should remain involved when possible, but an incident needs one decision-maker when several teams touch the same dependency.

Write the incident reference into the approval record. Scope it to the service and to the remediation action. Set a short expiration that matches the work, then close or revoke it when the incident ends.

Consider an agent asked to mitigate a runaway queue. It inspects metrics, proposes a configuration change, and requests a command that purges messages. The incident commander may approve a temporary concurrency adjustment after reviewing the rollback. They should not approve message deletion because it is fast. The request needs an explicit statement of which queue, which messages, which recovery path exists, and whether customers will lose work.

Speed comes from prepared authority paths, clear owners, and legible requests. It does not come from making every responder a production administrator for the afternoon.

Approval prompts should force a useful decision

A prompt fails when a competent owner cannot tell what they are approving in a few seconds. It also fails when it demands a novel security analysis for an ordinary action. The prompt should expose the decision points the owner already uses during normal operations.

Include the requester identity, agent process identity, action channel, credential label, target, operation, and scope. For a command, show the exact command and remote host. For an HTTP call, show the method, host, path, and a safe description of the body. Never display the secret itself as evidence that the credential exists.

This is the difference between useful and useless prompts:

Request: production configuration change
Process: signed coding-agent process, session 8f3a
Owner: billing-oncall
Credential: billing-admin
Action: PATCH https://api.internal.example/v1/routing/default
Body: {"provider":"secondary"}
Scope: one call
Reason supplied: mitigate provider timeout during INC-482

A prompt that says only "Allow tool access?" pushes the owner into ritual approval. It tells them neither the target nor the effect. If your tooling cannot produce enough context for a decision, it should deny the action until the requester provides it.

Do not put a free-form "reason" field in charge of safety. Agents can generate persuasive prose cheaply. Treat the reason as context for the human, while the system enforces the target, credential, and approval scope.

Audit records must answer the uncomfortable questions

After an unexpected change, people ask who approved it, what process made it, which credential it used, what target it reached, and whether someone later altered the record. An audit trail that cannot answer all of those questions is only a debugging aid.

Keep session decisions separate from individual action events, but connect them. A session record establishes the process and the approving owner. An activity record establishes each call or command and its result. Include denials and revocations. Failed attempts often explain a later workaround or reveal a process probing boundaries.

Make the record tamper-evident. A hash-chained log makes removal and modification detectable when someone can verify the chain independently. It does not turn a bad approval into a good one, and it does not replace access controls. It gives investigators a way to test whether the history still matches the recorded sequence.

Sallyport projects session and activity journals from a write-blind encrypted, hash-chained log, and sp audit verify can verify the chain offline over ciphertext. That design is useful because the reviewer does not need access to the operational secrets to test the record's integrity.

Do not bury agent actions in generic application logs. Those logs tend to omit the human decision, rotate quickly, and mix unrelated noise into the event trail. Keep a record that an on-call owner, security reviewer, and incident commander can each read without reconstructing a story from six systems.

Ownership failures usually begin with a convenient exception

The dangerous pattern starts with a reasonable shortcut. A senior developer needs to finish a migration. The service owner is in another time zone. Someone adds a general approval group, grants a reusable credential, or keeps a session alive through the weekend. The exception works, so it becomes the unofficial process.

Then the agent receives a broader task. It can reach more targets than its original request required. The original developer may be asleep, the owner may have rotated, and the broad group may assume someone else checked the prompt. Every individual decision looked defensible. Together they removed accountability.

Fix this by making exceptions structured rather than informal. An exception should name a service, approver, reason, end time, and review point. It should produce a visible record. It should not silently expand a developer's standing permissions.

Resist the popular recommendation to solve this with a sprawling rule engine. Rules look attractive because teams imagine they can encode every repository, branch, endpoint, time window, and job title. In practice, nobody can explain why a particular call matched, and stale rules become permissions nobody intended to keep. Start with a small decision model: vault access, a bounded session decision, and per-call confirmation for the actions that deserve it.

That model forces teams to settle the hard part in plain language: who owns this system right now, and what exactly are they willing to authorize?

Put the ownership model through a real shift test

You can find most design flaws before a serious incident by running one controlled exercise. Use a nonproduction system that resembles a service with a real on-call rotation. Start an agent session near a planned shift handoff, request a routine read, then request a change that needs individual confirmation.

Watch for the points where people hesitate. Can the outgoing owner see active sessions? Does the incoming owner know which service they now control? Does the approval request identify the process and target? Can either person revoke the session? Does the audit record show the denied, approved, and executed actions in order?

Do not accept "we would sort it out in chat" as an answer. Chat is useful for coordination, but it does not establish a decision boundary or preserve the complete action record. A handoff that depends on memory will fail on the busiest night.

Start by writing the active owner and backup for the first production service your agents can touch. Then make one agent request a bounded action against it. If you cannot identify the person who should approve that call without asking around, the agent has reached production before your ownership model did.