AI Agent Runtime Security Review
Make every delegation explicit. Examine who the agent acts for, where it can execute and which tools it can reach when instructions alone are not enough.
Inspect identity, execution and tools as connected controls
- Delegation boundary
- Trace the principal and the action they authorised.
- Execution boundary
- Limit the runtime resources and routes in scope.
- Tool boundary
- Validate target, arguments and confirmation conditions.
- Control evidence
- Connect each intended restriction to an observable check.
Engagement boundary
Agree the work and its boundaries together
The engagement boundary
- Delegation boundary
- Identity: workload identity for agents, credential lifecycle, user-to-agent and agent-to-agent delegation, least privilege, propagation across tools, attribution and revocation.
- Execution boundary
- The inputs, authorised access and client participants are confirmed before scheduling.
- Security owner
- Retains organisational decisions and risk acceptance.
- Additional implementation
- Runtime redesign and infrastructure changes are not implied by the review. Remediation verification can be added for named findings; subsequent connector or sandbox changes need their own checks.
What the work covers
- Identity: workload identity for agents, credential lifecycle, user-to-agent and agent-to-agent delegation, least privilege, propagation across tools, attribution and revocation.
- Sandbox: isolation boundaries, escape resistance, filesystem and network egress controls, secret exposure, resource limits, persistence and cleanup, auditability.
- Tools: permission scoping, description integrity, high-impact action confirmation, argument validation, connector trust, and unauthorised-use detection.
Scope boundaries
- Certification of a sandbox or identity platform; the assessment is scoped to your deployment.
- Implementation of identity infrastructure, unless separately agreed.
- Runtime redesign and infrastructure changes are not implied by the review. Remediation verification can be added for named findings; subsequent connector or sandbox changes need their own checks.
Decision and fit
Inspect identity, execution and tools as connected controls
Compare the engagement with the decision you face
- A question worth resolving
- Inspect identity, execution and tools as connected controls.
- An accountable participant
- Platform and security teams operating agents that run code, hold credentials or use tools with side effects.
- Inspectable source material
- The relevant owners can make workflow evidence and agreed inputs available for examination.
- A scope mismatch
- The assistant has no tool access, execution runtime or persistent credentials.
The engagement
Make every delegation explicit. Examine who the agent acts for, where it can execute and which tools it can reach when instructions alone are not enough. A coordinated runtime-boundary assessment covering identity, execution isolation and tool access within one deployment.
The decision at stake
The agent runs with broad credentials because narrow ones were hard to arrange, tools were added faster than their permissions were reviewed, and nobody can state precisely on whose behalf the agent is acting at any moment.
Suitable situations
- Platform and security teams operating agents that run code, hold credentials or use tools with side effects.
- Organisations adopting tool protocols or connector marketplaces and needing a boundary model before scaling.
- Teams running code-execution, browser or computer-use agents that need an isolation assessment.
Less suitable situations
- Read-only assistants with no tool access and no persistent credentials.
Working sequence
How the work moves from question to handover
What each stage should leave your team with
- Inventory authority
Identities, credentials and tools accounted for.
- Model intended boundaries
Explicit authority and isolation expectations.
- Assess actual boundaries
Configuration compared with the intended boundaries.
- Test selected boundaries
Authorised probe results with affected surfaces.
- Recommend and verify
Prioritised changes and verification responsibilities.
How the work proceeds
- Inventory authority. Enumerate identities, credentials, delegations and tools the agent uses, and how each was granted.
- Model intended boundaries. Define what the agent should be able to do, for whom, and under what confirmation, in a form that can be tested.
- Assess actual boundaries. Compare configuration, code and runtime behaviour to the intended model, including sandbox and network controls.
- Test selected boundaries. Exercise authorised probes for escalation, escape, secret exposure and unauthorised tool use.
- Recommend and verify. Prioritise changes, define policy tests, and confirm the boundaries with the team after remediation where agreed.
Worked situation
Follow one situation through to a bounded next decision
Illustrative working situation
Illustrative scenario
- Starting condition
A narrowly tasked agent reaches a broadly scoped connector.
- Question to examine
Follow identity, runtime and tool enforcement together.
- Possible next action
Specify the control change and the case that would verify it.
Decision artefacts
Leave a record the next owner can use
Authority boundary finding
Illustrative working format
- Subject and version
- Identify the workflow, configuration or proposal examined.
- Delegation boundary
- Record the relevant requirement and supporting material.
- Tool boundary
- State the observation, supporting evidence and remaining uncertainty.
- Security owner
- Record the next decision, follow-up and unresolved question.
What the work can produce
- Authority model describing identities, delegations, scopes and revocation paths.
- Isolation and tool-boundary assessment with findings and evidence.
- Prioritised control changes with verification steps for each.
- Policy tests that can be run to confirm the boundaries hold after changes.
Engagement notes
Read the detailed engagement considerations
How the detailed notes connect
- Delegation boundary
- Trace the principal and the action they authorised.
- Execution boundary
- Limit the runtime resources and routes in scope.
- Tool boundary
- Validate target, arguments and confirmation conditions.
Authority is the control that matters most
An agent’s capabilities are bounded far more by what it is allowed to do than by what it is instructed to do. Untrusted content can influence instructions; separately enforced permissions can restrict the resulting actions. The review therefore treats identity and delegation as the primary control, isolation as the second, and tool scoping as the third, and it looks for places where the practical difficulty of narrow permissions has been resolved by granting broad ones.
Making boundaries testable
Every intended boundary is written in a form that can be exercised: “the agent acting for user A cannot read records owned by user B”, “the code sandbox has no route to the internal network”, “a payment tool call requires a confirmation the user can see”. The policy tests produced by the review let the team confirm that the boundaries still hold after every change.
Working together
Your team and our team need a clear working agreement
Who contributes and who decides
- Client sponsor
- Confirms the decision, priorities and people needed to resolve it.
- Client technical or process owner
- Provides the agreed evidence, access and review of findings or deliverables.
- Softlander delivery lead
- Coordinates the agreed activities, review points, handover and open actions.
- Authorised decision-maker
- Accepts deliverables against the agreed criteria and separately decides operational or business action.
What the work depends on
- Your platform, identity and security contacts provide runtime configuration, connector definitions, network policies and a representative test environment. An authorised owner approves probes and stop conditions before execution.
- Access to identity configuration, secrets handling, sandbox and network policies, and tool definitions.
- Written authorisation for any active testing and an agreed environment.
Engagement availability
The start date, named delivery roles, review points and fee basis are agreed after confirming the inputs and scope. Duration depends on evidence access, system complexity and the time your decision-makers need to review the work.
Engagement and handover
Agree the delivery model and what completion means
A clear agreement from scope to ownership
- Scoped work
- Identity: workload identity for agents, credential lifecycle, user-to-agent and agent-to-agent delegation, least privilege, propagation across tools, attribution and revocation.
- Indicative handover
- Authority model describing identities, delegations, scopes and revocation paths; Isolation and tool-boundary assessment with findings and evidence.
- Review and acceptance
- Review the agreed deliverables and record any open items, owners and conditions.
- Ongoing work
- Assign maintenance and operational ownership; agree additional scope and coverage explicitly.
A coordinated runtime-boundary assessment covering identity, execution isolation and tool access within one deployment.
The assessment connects each tested boundary to its configuration, observed behaviour and reproducible case. The handover identifies untested surfaces and gives the platform owner a prioritised control backlog.
Runtime redesign and infrastructure changes are not implied by the review. Remediation verification can be added for named findings; subsequent connector or sandbox changes need their own checks.