A business owner asks whether a new AI agent is safe to connect to production. Engineering has a reassuring answer: it runs in a sandbox. Security asks a different question: can the identity behind the integration change customer records? The answer is yes. The integration needs that permission, even though the agent’s task does not.
This illustrative scenario captures a common assessment gap. Execution can be contained while an approved connection still gives the agent consequential access. A control can be working while an important exposure remains.
The useful next question is what the agent could still do to the business through the access available to it. That question connects technical boundaries to an accountable risk decision.
A control can be working while an important exposure remains.
Follow the boundary beyond execution
A sandbox controls the environment in which an agent operates. Its value depends on the boundaries it actually enforces, including the resources and services the agent can communicate with. Approved connections remain part of the review.
The NCSC’s Managing the cyber risk of agentic AI, published on 20 August 2026 as interim practical advice, asks designers to consider everything an agent can access or influence, directly or indirectly. That includes network access, credentials and authenticated sessions. It recommends restricting access to the resources needed for the task, maintaining human oversight for higher-risk scenarios, and preparing to halt activity across the wider system.
A practical assessment follows that access into the business process. The environment determines what is reachable. Identity and permissions determine the actions those systems allow. Business context determines the consequences of those actions.
Environment
Which systems are reachable?
Identity
What will those systems allow?
Business context
What are the consequences?
Ask what the deployment review leaves open
A deployment review may confirm that a sandbox is enabled, authentication is configured, activity is logged and a shutdown procedure exists. Each item matters. Each also needs a test that reflects the actual workflow.
Reachable systems
Which sensitive services remain reachable through approved connections? Include indirect access through tools, proxies and shared integrations.
Effective permissions
Does the identity permit actions beyond the agent’s approved purpose? A valid login can still carry an excessive role.
Traceable activity
Can a consequential action be linked to the agent’s identity and accountable owner, and then to the affected business service? Shared accounts can make attribution harder.
Tested interruption
Has the team tested stopping execution and cutting off the relevant access? Include requests or downstream jobs already in progress.
Controls are configured
Sandbox enabled
Authentication configured
Activity logged
Shutdown procedure documented
Exposure is understood
Reachable systems mapped
Permissions tested against purpose
Actions linked to accountable owners
Interruption tested across the access path
Trace one permission to its consequences
Consider an agent assigned to investigate payment failures. Its integration uses a shared account that can write to customer records. The task requires investigation, yet the effective permissions also allow changes to information used by the payment process.
The exposure path runs from the agent to the shared identity, into writable customer data and onward to payment settlement. A mistaken or unintended change could disrupt that service. The business consequences could include interrupted revenue and damage to customer trust.
The assessment should identify the permissions and dependencies that make the scenario credible. It should also record the assumptions that have not been validated. This is an illustrative failure scenario, rather than a claim about a reported incident.
A focused response could be to give the investigation workflow a dedicated read-only identity, with a separate, technically enforced approval path for changes. The right control depends on the service and the actions the agent genuinely needs.
Use five dimensions for the risk decision
DataObserve’s five-part framing brings the technical evidence into a business decision. It is informed by the NCSC advice and is separate from the NCSC’s own guidance and maturity models.
Business scope
Which business outcome could be disrupted if the agent acts outside its task? Define the affected service and the boundaries of the approved workflow.
Identity and effective access
Can the access available to the agent exceed its approved purpose? Include credentials, inherited roles and authenticated sessions that can be reached indirectly.
Validated controls
What evidence shows a prohibited action is actually prevented? Retain the test conditions and results, along with any limits on the conclusion.
Business-impact priority
Which change offers the most meaningful reduction in business risk? Consider the affected service, credible loss scenarios and uncertainty in the assessment.
Verified closure
Can the team show what changed and why the remaining risk is acceptable? Record the accountable decision-maker and the conditions that trigger another review.
Start with one consequential workflow
Choose a workflow where an unintended action could affect an important business outcome. A bounded assessment is easier to test and revisit than a general declaration that an entire agent platform is safe.
Define the approved purpose
Specify what the agent may do, what it must avoid and when it needs human approval. Tie those boundaries to the business owner’s intent.
Trace the available access
Map the identity used by each connection. Include credentials and sessions available through the surrounding environment, even when the agent is not intended to use them.
Build a credible failure scenario
Describe how an out-of-scope action could affect a service or its data. Make the business consequence explicit and distinguish evidence from assumptions.
Validate the safeguards
Use authorised tests within an agreed scope. Check both permitted and prohibited actions. Retain evidence that shows where enforcement happens.
Close the loop
Verify the change, retest the relevant path and record any accepted residual risk. Revisit the assessment when permissions, tools or workflow scope change.
Write access exceeds the task
Constrain the investigation identity
Retest the prohibited action
Make the decision defensible
A defensible decision preserves the path from the finding to the affected business service. It names an owner, explains the proposed change and includes the evidence used to accept the outcome.
For material exposures, FAIR-based analysis can help structure the business-impact discussion around loss scenarios and ranges. Its usefulness depends on visible assumptions and evidence quality. Any estimates should remain distinguishable from measured outcomes.
Agents can support investigation and recommendations within their authorised scope. People remain accountable for approvals and risk acceptance. A completed remediation task becomes evidence of closure only after the relevant exposure has been checked again.
This is the assessment approach behind the S.A.F.E perspective in the original carousel. Explore DataObserve S.A.F.E or discuss a consequential workflow with the team.
Source and original carousel
NCSC: Managing the cyber risk of agentic AI, Toby W, 20 August 2026. The publication describes its advice as interim and notes that effective practice will continue to evolve.
Download the original DataObserve S.A.F.E carousel (PDF). This article adapts its assessment framework into a website reading format.
The five dimensions are a DataObserve framing, not an NCSC maturity model or certification scheme. The scenarios describe assessment considerations and do not establish a security certification or the implementation status of a product integration.
Start with the access available to one agent. Follow it to the business outcome that matters.
Which permission would you review first in your most consequential agent workflow?
Technical safeguards require workflow-specific validation. Risk acceptance remains an accountable business decision.