After OpenShell stops an agent, find out what already changed

Imagine watching an agent ask Kubernetes for more copies of the checkout service. Then a security control stops it. The agent is quiet, but the request has already left. Did checkout get its extra capacity? Before anyone presses resume, someone needs to look where that request landed.

That small gap between sending and knowing is worth keeping in view when reading NVIDIA’s September 28 Open Agent Safety Platform launch. The platform pairs OpenShell access controls with Sentry, a separate watcher that can enforce limits using BlueField-4 data processing units. Stopping an agent can prevent its next action. An earlier request, already accepted elsewhere, has a life of its own. The checkout interruption here is a teaching example, not a reported incident.

Find the boundary the request crossed

Suppose our checkout agent gathers a diagnostic bundle and tries to send it to a new service. OpenShell does not treat permission to reach a host as permission to send any available credential there. Those are two separate checks. In this example, the network rule allows the host, but the credential is not bound to that destination. The authenticated request is blocked, even though the connection would otherwise be allowed.

That detail changes the repair. The responder needs to identify the control that denied the request, then review the particular destination, operation and credential binding if the task genuinely needs them. As the provider guidance explains, the workload can use placeholders while the real credentials stay outside it and are attached to authorized requests. Copying a real key into the diagnostic bundle would sidestep the protection we were trying to repair.

Before widening access, the policy prover can compare the proposed permissions with a boundary supplied by the operator. It works on a mathematical model: does the represented access fit inside the represented limit? That is a useful, specific answer. It does not establish everything the permitted application might do, or decide whether sending this particular bundle is a sensible operational choice.

Change one detail: the agent needs a local file, not a new destination. Now a network-rule edit will not help. Validated network changes can take effect while the sandbox runs; filesystem restrictions are set at startup, and process identity at creation. The historical policy architecture link was unavailable when checked on November 2, 2026. The current policy lifecycle documentation linked below supports these different lifetimes. A newly required startup permission may mean reviewing and creating a fresh sandbox, rather than trying to loosen the running one.

Sentry adds another way to stop the work. It watches from outside the agent’s execution path, which is what out-of-band means here. NVIDIA’s layered reference design puts that watcher on BlueField-4 hardware and describes quarantine in milliseconds. That timing is NVIDIA’s claim, not a benchmark from this article. Nor does an ordinary OpenShell installation necessarily include the full Vera/BlueField arrangement. Either kind of stop leaves us with the same checkout question: what had already happened?

The request reached Kubernetes first

Give the example some numbers. The agent has approval to increase checkout-api from 12 replicas, the running copies of the service, to no more than 20 under a specified saturation condition. Approval was based on resource version 8841, an identifier for the state the reviewer saw. The agent asks for 16:

PATCH Deployment checkout-api

current replicas: 12
requested replicas: 16
state precondition: resourceVersion 8841

Kubernetes accepts the change. Before the agent can read the rollout result, a later forbidden outbound request is denied, or an independent control quarantines the agent. The stop succeeds. The check on the earlier scale request never finishes.

We now need to read the destination: how many replicas are desired, how many are available, whether anything changed afterward, what the agent still has queued, and whether customers can complete checkout. The extra capacity may already have helped. It may have exposed another problem. Another controller may have changed the deployment again while the agent was stopped.

Which blocked requests need a responder?

A forbidden connection from a disposable test is not automatically an incident. If the control stopped it before any consequential effect, the denial may simply show that a restriction worked. Checkout deserves closer attention because a production change could already be underway:

What happened	Why it needs attention
A consequential write may have preceded the stop	The destination may already have changed, with its result still unknown.
The agent was quarantined	Work cannot safely continue until its earlier actions are reconciled.
Required production work was interrupted	The security control may have succeeded while reliability remains affected.
The agent asked for unexpected additional authority	Its behavior may no longer fit the task or policy that was reviewed.
The same unexpected denial returned after a correction	The workflow may be drifting, or the policy may still be wrong.
The destination cannot be inspected	There is not yet a safe basis for declaring recovery.

Route the event according to what it could have affected. Paging for every successful block makes the consequential interruption harder to notice. A disposable test with no write-capable tools may need only a record of the denied connection. When there is strong support that nothing consequential could change, there is no reason to manufacture a full recovery exercise.

Keep the next action from hiding the first

Pause further consequential writes, while keeping safe read-only inspection available where possible. That gives the responder a chance to connect the stopped task to its unfinished request. A record like this can hold the pieces together:

containment_event:
  agent_id:
  sandbox_id:
  task_id:
  policy_version:
  event_time:
  blocked_operation:
  last_confirmed_operation:
  possible_inflight_operation:
  target:
  target_state_version:
  execution_id:
  queued_actions:

This is an SRE template, not an OpenShell schema. Its practical job is to help another person locate the API operation without reopening write access just to investigate it. Keep the relevant record, not an unnecessary copy of the secrets that happened to be nearby.

Ask the system that received the request

The agent’s history tells us where to look. A missing confirmation does not tell us what Kubernetes did. Read the Deployment’s current resource version, desired and available replicas, rollout conditions, and relevant audit or controller records. Different answers lead to different next steps:

What the destination shows	What follows
The approved write is confirmed and still current	Check the service outcome. If the customer objective is met and no work remains, close the task without resuming the agent.
The write happened, followed by another change	Reassess the task from the state that exists now.
The destination establishes that the write did not happen	Decide whether a new attempt is still justified and authorized.
Records are incomplete or disagree	Keep the outcome explicitly unknown.
Inspection cannot be done safely	Hold further writes and give the unresolved action an owner.

Even an empty lookup may leave the result unsettled: records can arrive late or omit part of the operation. Keep that outcome explicitly unknown. This observation:

I did not receive proof that the write succeeded

does not establish this conclusion:

The write failed, so send it again

The unknown-write guide follows this same problem in other automation. Here, the stopped agent may be unable to inspect anything at all. Someone outside that execution path needs to finish the check.

Twelve replicas may already have become eighteen

While the sandbox is stopped, an autoscaler or a colleague can keep working. The approval still describes this earlier view:

replicas = 12
resourceVersion = 8841
requested replicas = 16

But a fresh read could show:

replicas = 18
resourceVersion = 8897

Sending the old target of 16 now would reduce a deployment that has already reached 18. The same number has changed from an increase to a decrease. Revisit the saturation objective and obtain whatever authorization the current policy requires for the current state. Restarting a process does not update the decision it was about to carry out.

The location of the model does not change this problem. A local model can act on an old view just as a cloud model can; the local-agent boundary guide explores that distinction in another runtime.

Give the repair a specific address and purpose

If the remaining work needs one read endpoint, name that endpoint, the method and the credential permission. Someone can review that request. “Stop blocking the agent” leaves them guessing about the access being granted. Unrestricted outbound access is a much larger change than the missing capability in our example.

Match the repair to the boundary: a validated dynamic network-policy change for network access, or a newly reviewed sandbox when startup filesystem or process restrictions require one. The policy lifecycle explains when those changes can take effect.

The same reasoning favors a namespace over a whole cluster, one repository over an organization, and a reconciled action over the entire old queue. And if checkout has already recovered, there may be no missing capability to grant. The right treatment of the queued scale request may be to discard it.

Try the checkout customers came to use

Sixteen available replicas tell us that the deployment reached a particular state. Customers came to buy something, not admire a replica count. An independent check can record both the service result and whether the control path is working:

verification:
  deployment_available_replicas: 16
  request_error_rate: recovered
  p95_latency: recovered
  synthetic_checkout: pass
  unexpected_policy_denials_after_resume: 0

These are illustrative values, not measurements or universal thresholds. The latency entry refers to the duration at or below which roughly 95% of the relevant requests fall; its population, window and recovery target still need to be defined for the service. Healthy replicas with failed checkout leave the service task open. Healthy checkout with repeated unexpected denials means the execution controls still need attention.

The production-action guide connects permission to act with verification afterward. A successful block answers one question; a successful API write answers another. Neither alone tells us that the customer’s problem is over.

One minute to find the write, three to confirm recovery

Put a clock on this invented interruption. At 10:02, the agent is contained with one scale request still unresolved. At 10:03, the responder finds the matching destination record: Kubernetes received the change. The count of unknown actions drops from one to zero. Resolving that uncertainty took one minute, but nobody has yet established that checkout works.

At 10:05, the agreed customer-path checks confirm recovery. That makes three minutes from containment to verified recovery, not one. If the resumed agent then encounters the same unexpected denial, checkout may be healthy while its workflow remains broken. These are hypothetical times, chosen to make the separate intervals visible.

A small set of local measures can keep those distinctions available after the incident. These names are proposed for the team’s own tracking, not supplied as native OpenShell metrics:

Local measure	Question to ask
Expected policy denials	Are the known restrictions being enforced?
Unexpected policy denials	Which normal workflows are meeting limits nobody planned for?
Quarantined agents	How often does execution require stronger containment?
Unknown in-flight actions	How many consequential actions still have unresolved outcomes?
Reconciliation latency	How long until we establish what changed?
Stale-authority rejections	How often has production moved on before execution or resumption?
Repeat denial after resume	Did the repair actually fix the control path?
Containment to verified recovery	How long until we understand both the service and execution state?

An operation identifier may have a different value for almost every request. Keep those high-cardinality identifiers in protected logs or traces, rather than creating a metric label for each one. Also keep expected denials recognizable as successful enforcement. A falling denial count might mean a smoother workflow, or it might mean weaker restrictions. Look at unexplained denials and unresolved actions before deciding which story the count tells.

Practice the stop before the agent touches production

The permission policy needs a recovery procedure beside it. This template keeps the decisions from our checkout example in one place:

containment_runbook:
  classify:
    expected_or_unexpected:
    possible_prior_side_effect:
    production_work_interrupted:

  preserve:
    agent_id:
    sandbox_id:
    task_id:
    policy_version:
    last_confirmed_operation:
    possible_inflight_operation:

  reconcile:
    destination_source_of_truth:
    current_state:
    operation_evidence:
    result: confirmed | rejected | unknown

  authority:
    original_precondition:
    current_precondition:
    fresh_approval_required:

  resume:
    minimum_policy_change:
    new_sandbox_required:
    queued_work_disposition:

  verify:
    service_postcondition:
    control_postcondition:
    accountable_owner:

Use a synthetic or nonproduction rehearsal to stop execution before a write, after it, and while its result is unknown. Change the target during quarantine. Try both the live network-policy repair and the fresh-sandbox path. Include a failed service check and a denial that returns after resumption, so the exercise does not end at the first successful restart.

Ask the responder to explain the current state and the next authorized decision at each interruption. A task that eventually finishes can still have made a duplicate change or relied on an approval that no longer applied.

Back at checkout, the useful ending may be pleasantly uneventful: the change committed, the replicas became available, customers recovered, and the agent has nothing left to do. Or another controller has moved the deployment on, and the old plan belongs in the history rather than the queue. The destination tells us which ending we have. Resume comes after that answer, if it is needed at all.

Continue with the unfinished-write problem

• Unknown write reconciliation
• Production agents: authorize the action, then verify the outcome
• Evaluate incident-response agents against service outcomes

Documentation behind the controls

• NVIDIA Sentry announcement
• OpenShell runtime and credential controls
• OpenShell policy prover documentation
• Historical OpenShell policy architecture (unavailable November 2, 2026)
• NVIDIA reference architecture
• OpenShell policy lifecycle
• OpenShell provider and credential documentation

Evidence and scope: Technical sources were reviewed September 29, 2026. NVIDIA’s timing and containment results remain attributed vendor claims, not independent benchmarks. The Kubernetes sequence, recovery templates and measures illustrate an SRE procedure; they do not report a production incident or define native OpenShell schemas.