AI Secure Agent Deployment Review
Look beyond a successful demonstration. Examine the permissions, dependencies and operational controls that shape an agent’s behaviour in deployment.
Connect deployment threats to controls and remaining risk
- Threat entry
- Identify untrusted content and exposed interfaces.
- Effective authority
- Inspect real credentials, tools and data routes.
- Control placement
- Locate prevention, detection and containment points.
- Residual finding
- State what the examined controls leave unresolved.
Engagement boundary
Agree the work and its boundaries together
The engagement boundary
- Threat entry
- Threat model for the agent as deployed, covering injection through content and tool descriptions, privilege escalation, data exfiltration, memory and retrieval poisoning, and cross-agent effects.
- Effective authority
- The inputs, authorised access and client participants are confirmed before scheduling.
- Release risk owner
- Retains organisational decisions and risk acceptance.
- Additional implementation
- Remediation implementation, incident response and later release reviews are separate work. A retest can be scoped to changed controls and named findings; no review establishes that all vulnerabilities are absent.
What the work covers
- Threat model for the agent as deployed, covering injection through content and tool descriptions, privilege escalation, data exfiltration, memory and retrieval poisoning, and cross-agent effects.
- Architecture review of trust boundaries, tool access, credential handling, network egress, isolation and logging.
- Control review against the threat model, including confirmation steps, rate and scope limits, containment and monitoring.
- Targeted testing of selected findings where safe and authorised.
- Risk-ranked findings and a sequenced remediation plan.
Scope boundaries
- Legal advice, penetration-testing certification, or statements of compliance with a regulation or standard.
- Guarantees that no vulnerabilities remain; the review covers a defined scope by a defined method.
- Remediation implementation, unless separately agreed.
- Remediation implementation, incident response and later release reviews are separate work. A retest can be scoped to changed controls and named findings; no review establishes that all vulnerabilities are absent.
Decision and fit
Connect deployment threats to controls and remaining risk
Compare the engagement with the decision you face
- A question worth resolving
- Connect deployment threats to controls and remaining risk.
- An accountable participant
- Security and release owners assessing a running agent deployment with consequential permissions or data access.
- Inspectable source material
- The relevant owners can make workflow evidence and agreed inputs available for examination.
- A scope mismatch
- You require an accredited security assessment or regulatory attestation.
The engagement
Look beyond a successful demonstration. Examine the permissions, dependencies and operational controls that shape an agent’s behaviour in deployment. A scoped deployment security assessment combining configuration review, threat analysis and authorised targeted tests.
The decision at stake
An agent has access to data and tools that matter, the security team has not reviewed agentic systems before, and the release decision is being made on the basis of conventional application security alone.
Suitable situations
- Security and release owners assessing a running agent deployment with consequential permissions or data access.
- Teams preparing a release decision who need an explicit statement of residual risk.
- Organisations integrating third-party tools, connectors or protocol servers into an agent.
Less suitable situations
- Model-level red teaming in isolation from the deployed system; the review is about the system as deployed.
- Organisations seeking a formal certification or accredited assessment.
Working sequence
How the work moves from question to handover
What each stage should leave your team with
- Establish scope and authority
A written system boundary and testing authority.
- Model the threats
Threats relevant to the deployment.
- Review architecture and controls
Design and configuration gaps with evidence.
- Test selected findings
Observed impact of authorised targeted tests.
- Rank and plan
Risk-ranked remediation and a release briefing.
How the work proceeds
- Establish scope and authority. Agree the system boundary, environments, testing permissions and rules of engagement in writing.
- Model the threats. Describe the agent's inputs, authority, tools and data flows, and derive the threats that matter for this system.
- Review architecture and controls. Examine design, configuration and code where available against the threat model, recording gaps as findings.
- Test selected findings. Confirm exploitability and impact of prioritised findings using agreed, authorised methods.
- Rank and plan. Produce the findings register and remediation plan, then brief the release decision-makers.
Worked situation
Follow one situation through to a bounded next decision
Illustrative working situation
Illustrative scenario
- Starting condition
An allowed tool route exposes more data than its task requires.
- Question to examine
Review the deployed control and test only as authorised.
- Possible next action
Rank remediation and brief the accountable release owner.
Decision artefacts
Leave a record the next owner can use
Deployment finding
Illustrative working format
- Subject and version
- Identify the workflow, configuration or proposal examined.
- Threat entry
- Record the relevant requirement and supporting material.
- Control placement
- State the observation, supporting evidence and remaining uncertainty.
- Release risk owner
- Record the next decision, follow-up and unresolved question.
What the work can produce
- Threat model and trust-boundary diagram for the deployed agent.
- Findings register with severity, evidence, affected components and recommended remediation.
- Remediation plan sequenced by risk reduction and effort.
- Briefing for the release decision that states residual risk plainly.
Engagement notes
Read the detailed engagement considerations
How the detailed notes connect
- Threat entry
- Identify untrusted content and exposed interfaces.
- Effective authority
- Inspect real credentials, tools and data routes.
- Control placement
- Locate prevention, detection and containment points.
The properties that change the review
Three properties recur in agentic systems and shape the review. First, the agent reads content it did not author, such as documents, web pages, tickets and tool results, and that content can carry instructions. Second, the agent holds authority, usually credentials or delegated permissions, that lets it act. Third, the agent can move data between the two. When all three are present without separately enforced controls, the model’s judgement may be the remaining barrier between an attacker’s text and a real action. The review examines which architectural controls restrict those effects.
What a finding looks like
Each finding records the threat it relates to, the component affected, the evidence observed, the severity with its reasoning, and a remediation recommendation with an estimate of effort. Findings are written so that an engineer can act on them and a risk owner can understand them without a translation layer.
Residual risk is stated, not hidden
The release briefing states what was examined, what was found, what has been remediated and what remains. Where a control cannot be implemented before release, the briefing records the compensating measures and who accepted the risk. This is the material a governance function needs to make a defensible decision.
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
- Provide the deployment owner, security contact, architecture and configuration evidence, plus a representative environment. Written testing authority defines allowed actions, data handling and escalation before any active probe.
- Architecture documentation, tool and connector definitions, and access to configuration and code where possible.
- A test environment representative of production, or agreement on safe testing in production.
- Written authorisation for any active testing.
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
- Threat model for the agent as deployed, covering injection through content and tool descriptions, privilege escalation, data exfiltration, memory and retrieval poisoning, and cross-agent effects.
- Indicative handover
- Threat model and trust-boundary diagram for the deployed agent; Findings register with severity, evidence, affected components and recommended remediation.
- 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 scoped deployment security assessment combining configuration review, threat analysis and authorised targeted tests.
Each material finding identifies the deployment version, supporting evidence, impact reasoning and remediation owner. The release briefing distinguishes tested controls, unresolved risks and surfaces that could not be examined.
Remediation implementation, incident response and later release reviews are separate work. A retest can be scoped to changed controls and named findings; no review establishes that all vulnerabilities are absent.