AI Secure Agent Architecture Review
Design authority and isolation into the system. Review trust boundaries, credentials, tools and recovery before deployment choices become difficult to change.
Resolve authority and isolation choices while design can change
- Input trust
- Separate external content from control instructions.
- Credential path
- Map privileges from workload to downstream service.
- Execution zone
- Locate runtime, network and tenant separation.
- Recovery control
- Identify containment and restoration responsibilities.
Engagement boundary
Agree the work and its boundaries together
The engagement boundary
- Input trust
- Map trust boundaries, credentials, data flows and tool interfaces.
- Credential path
- The inputs, authorised access and client participants are confirmed before scheduling.
- Architecture owner
- Retains organisational decisions and risk acceptance.
- Additional implementation
- Implementation and testing of the deployed configuration are separate stages. A deployment review or targeted boundary test can verify controls once there is a representative running system.
What the work covers
- Map trust boundaries, credentials, data flows and tool interfaces.
- Examine privilege, isolation, dependency trust and recovery choices.
- Document design tradeoffs and prioritise controls before implementation.
Scope boundaries
- Formal certification, legal conclusions and guarantees of safe or compliant behaviour.
- Implementation or ongoing operation beyond the agreed scope.
- Implementation and testing of the deployed configuration are separate stages. A deployment review or targeted boundary test can verify controls once there is a representative running system.
Decision and fit
Resolve authority and isolation choices while design can change
Compare the engagement with the decision you face
- A question worth resolving
- Resolve authority and isolation choices while design can change.
- An accountable participant
- Architects and security leads selecting agent trust boundaries before implementation choices become expensive to change.
- Inspectable source material
- The relevant owners can make workflow evidence and agreed inputs available for examination.
- A scope mismatch
- The immediate task is implementing the entire architecture.
The engagement
Design authority and isolation into the system. Review trust boundaries, credentials, tools and recovery before deployment choices become difficult to change. A design-stage security review of a proposed architecture and its consequential authority or data flows.
The decision at stake
Architecture choices are expanding what an agent can reach before security boundaries have been agreed.
Suitable situations
- Architects and security leads selecting agent trust boundaries before implementation choices become expensive to change.
Less suitable situations
- The immediate task is implementing the entire architecture.
Working sequence
How the work moves from question to handover
What each stage should leave your team with
- Map authority and data flows
A trust-boundary map of the intended system.
- Challenge the trust assumptions
Risks tied to authority and information flows.
- Compare design alternatives
Feasible controls compared with alternatives.
- Record decisions and verification needs
Design decisions and implementation verification needs.
How the work proceeds
- Map authority and data flows. Describe who initiates tasks, what tools can change and where trusted and untrusted information crosses boundaries.
- Challenge the trust assumptions. Examine identity, isolation, connector trust and recovery choices against realistic misuse paths.
- Compare design alternatives. Evaluate narrower permissions, separation of duties and containment options against the workflow's constraints.
- Record decisions and verification needs. Deliver prioritised architecture changes and checks that must be performed on the implemented system.
Worked situation
Follow one situation through to a bounded next decision
Illustrative working situation
Illustrative scenario
- Starting condition
A proposed connector crosses two trust zones with one identity.
- Question to examine
Compare narrower permission and isolation options.
- Possible next action
Record the design tradeoff and implementation prerequisite.
Decision artefacts
Leave a record the next owner can use
Architecture decision
Illustrative working format
- Subject and version
- Identify the workflow, configuration or proposal examined.
- Input trust
- Record the relevant requirement and supporting material.
- Execution zone
- State the observation, supporting evidence and remaining uncertainty.
- Architecture owner
- Record the next decision, follow-up and unresolved question.
What the work can produce
- Trust-boundary architecture map
- Architecture findings and tradeoffs
- Control implementation priorities
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
- Architects, identity owners and business sponsors supply system diagrams, proposed tools, trust assumptions and deployment constraints. They participate in threat walkthroughs and compare feasible design alternatives.
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
- Map trust boundaries, credentials, data flows and tool interfaces.
- Indicative handover
- Trust-boundary architecture map; Architecture findings and tradeoffs
- 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 design-stage security review of a proposed architecture and its consequential authority or data flows.
Architecture decisions record the risk addressed, alternatives considered and control responsibilities. The handover identifies assumptions that must be verified once the system is implemented, rather than claiming the design has been tested in operation.
Implementation and testing of the deployed configuration are separate stages. A deployment review or targeted boundary test can verify controls once there is a representative running system.