An agent investigating failed checkouts finds a service that needs a restart. It has read the logs, identified a plausible cause and chosen a reasonable next step. The investigation is useful. Restarting production is a different assignment.
This is a practical problem for teams introducing agents into business systems. The same access that makes an agent helpful can let it complete work nobody authorized. An attacker is not required: the agent may simply treat an obstacle as something it should fix.
OpenAI’s August 2026 guide Agent security in the enterprise makes this distinction central to deployment design. At Oktsec, we would turn it into a review of one real workflow: what the agent needs to do, which effects require a separate decision and where those limits are enforced.
Access does not define the assignment
OpenAI illustrates the problem with invoice processing. An agent notices that a document-signing subscription is about to expire and attempts a renewal to keep the work moving. The vendor and payment amount may be allowed, while the new commitment falls outside the assigned task. A transaction limit alone does not resolve that distinction. Read the invoice example, printed page 4.
For our checkout example, the assignment should specify the service and time window to investigate. The agent can retrieve the relevant logs and prepare a diagnosis. Production credentials and restart tools do not belong to that role. If a change is needed, an engineer reviews the proposed effect and authorizes it through the existing change process.
That separation should be enforced through permissions. A prompt asking the agent to seek approval cannot compensate for a credential that already permits the change.
- Assigned workRead the relevant logs
Use access limited to the service and records needed for the investigation.
- Additional actionPropose a restart
The diagnostic agent can explain the proposal. Its tool permissions exclude execution.
- Independent decisionReview the change
An authorized engineer decides whether to proceed through the production change process.
Review what can happen before the next approval
OpenAI distinguishes the resources an agent can reach, the harm still possible after controls are applied and the most consequential effect it can complete before another independent decision. These are useful questions because an inventory of connected tools does not reveal the whole exposure. Reach and blast radius, printed page 5.
Consider a support agent that reads customer cases and drafts replies. Approval before sending a message protects that send operation. It does not undo an unnecessary read of sensitive records. It also does not prevent disclosure through a separate upload tool or an unrestricted network request.
Review the combination of data access and destinations. Limit the records available to the task, identify where their contents can leave the environment and test those paths together. Read-only access can still expose information; it is not a complete containment strategy.
A tool update can change the permission you granted
A connector approved for searching tickets may later expose record updates or external sharing. A familiar service name can hide a materially different capability. OpenAI recommends reviewing action and schema changes and testing combinations of capabilities, including sensitive reads paired with external sends. Tools and capability composition, printed pages 16–17.
Keep an owner and expected effect for each approved tool. Before an update reaches a production agent, compare the available operations and parameters with the approved configuration. New actions should require review. An explicit allowlist can reject a newly named tool, but it does not establish that an existing tool still behaves the same way.
For MCP deployments, include backend versions, parameter constraints and outbound access in that review. A generic shell or HTTP tool may recreate an operation that a more specific tool restriction was supposed to prevent. Test the restriction against the capabilities the agent actually has.
Put the control where the effect occurs
The guide treats runtime isolation, resource permissions, network controls and approvals as complementary layers. A harness coordinates execution; that alone does not make it a sandbox. Model-based review can help identify ambiguity, but consequential limits need controls that remain effective when the model makes a mistake. Runtime and control placement, printed pages 18–20.
For a coding workflow, that means protecting branches and deployment credentials in the systems that own them. For a data workflow, enforce access at the source and restrict outbound destinations. A gateway adds checks on the requests routed through it. The surrounding environment must also prevent an agent from reaching the same resource by an unchecked route.
When a limit blocks legitimate work, show the operator the requested action, affected resource and reason. The exception process should approve a specific change in scope. Broadening credentials until the task succeeds makes the next run harder to control.
Keep the policy decision separate from the final effect
A gateway can record that it rejected a restart request. That record does not establish that the service was never restarted through another path. An allowed request likewise does not prove that the destination completed it.
- Task and requestWhat was attempted?
Identify the requester, agent, assignment, tool and target service.
- Enforcement recordWhat did policy decide?
Retain the decision, reason and configuration in effect for the request.
- Destination evidenceWhat actually changed?
Use service and deployment records to establish the observed effect.
OpenAI’s response guidance also separates stopping execution from revoking authority. Terminating a task may leave issued tokens usable. Revoking a credential may leave previously accepted work running. A response drill should cover both, including downstream sessions and delegated work. Observability and response, printed pages 24–26.
Collect the identifiers and decision metadata needed for that investigation without turning the audit trail into another store of customer records or secrets. A tamper-evident record helps verify integrity. It does not guarantee that every relevant event was captured.
Test one workflow before expanding its access
Start with a task whose useful outcome is clear. Confirm that approved work succeeds with the intended permissions. Then test a request outside scope, malicious instructions in retrieved content and an alternative route to the restricted action. Retain the configuration and results so a later tool update can be checked against them.
Oktsec Control applies deterministic checks to actions routed through its configured enforcement points, including tool permissions and supported parameter constraints. It evaluates policy rather than inferring every business intention. Source-system permissions and runtime isolation remain part of the deployment.
Our free agent workflow check can help frame the initial access questions. For technical validation, an agent security assessment tests the configured paths and plausible bypasses within an agreed scope. The evidence workflow explains what to retain for review.
The same distinction applies to security agents preparing patches. Our Defense Factory analysis follows their work through validation and deployment. Greater autonomy is useful when the team can explain which work was delegated, which effects were permitted and how the result was checked.
Source and scope
Based on OpenAI’s Agent security in the enterprise, published August 2026 and reviewed September 12, 2026. Page references identify the guide’s printed pagination; links open the corresponding PDF pages. The checkout scenario and deployment recommendations are Oktsec’s analysis. The guide is not a certification or an endorsement of Oktsec.