System decomposition and architecture patterns
Threat scoring without a clear system model produces generic results. MAESTRO therefore begins with decomposition.
The linked System Record and Intake first establish whether architecture, model, data, tools, orchestration, ecosystem or human-interaction exposure requires MAESTRO screening. Unknown material architecture facts remain screening work. The decomposition below then supplies the layer-specific threat model; routing does not set threat applicability or risk scores. See Routing and applicability.
Choose the assessment subject
Section titled “Choose the assessment subject”The Assessing system selector determines the active MAESTRO score bucket:
- Select a registered AI system for a system-level threat model.
- Select workspace scope only for a deliberate shared-platform or pre-registration review.
- Switching systems changes the active likelihood, impact and severity records.
- Workspace roll-up shows coverage and worst-case exposure without replacing system-level analysis.
Do not combine unrelated systems into one threat model merely because they share a workspace.
Four required decomposition fields
Section titled “Four required decomposition fields”Components and trust boundaries
Section titled “Components and trust boundaries”Record:
- Foundation model and version.
- Fine-tunes, adapters and model endpoints.
- Data sources, vector stores, memory and feedback stores.
- Agent framework, orchestrator and plugins.
- Tools, APIs, queues and business systems.
- Workload, container, network and cloud boundaries.
- Human approval points.
- External agents, suppliers, registries and marketplaces.
- Identity and credential boundaries.
- Entry and egress points.
Agent capabilities and tools
Section titled “Agent capabilities and tools”State what the system can actually do:
- Read, create, modify or delete data.
- Send messages or publish content.
- Execute code or commands.
- Make payments or commercial commitments.
- Change infrastructure or security configuration.
- Create or delegate work to agents.
- Learn from interactions or update persistent memory.
- Reach production, regulated or safety-relevant environments.
Goals and immutable constraints
Section titled “Goals and immutable constraints”Record:
- Intended objective.
- Prohibited objectives.
- System and policy instructions.
- Approval requirements.
- Transaction, time, volume and cost limits.
- Data-use and jurisdiction restrictions.
- Stop conditions.
- Whether the agent can alter, reinterpret or delegate its goal.
Interactions
Section titled “Interactions”Map:
- User-to-agent interactions.
- Agent-to-tool calls.
- Agent-to-agent messaging.
- Data ingestion and retrieval.
- Model invocation.
- Human feedback and approval.
- External environment signals.
- Supplier and marketplace interactions.
- Monitoring and response loops.
Eight canonical architecture patterns
Section titled “Eight canonical architecture patterns”| Pattern | Description | Canonical threat focus |
|---|---|---|
| Single-Agent Pattern | One agent independently pursues a goal | Goal manipulation |
| Multi-Agent Pattern | Multiple agents communicate and collaborate | Communication-channel and identity attacks |
| Unconstrained Conversational Autonomy | Broad conversational inputs with limited task constraints | Prompt injection and jailbreaking |
| Task-Oriented Agent Pattern | An agent performs a defined task, often through APIs | Denial of service through overload |
| Hierarchical Agent Pattern | Higher-level agents direct subordinate agents | Compromise of a higher-level agent |
| Distributed Agent Ecosystem | Decentralised agents operate in a shared environment | Sybil and agent-impersonation attacks |
| Human-in-the-Loop Collaboration | Humans and agents iteratively influence decisions | Manipulation of human input or feedback |
| Self-Learning and Adaptive Agents | The agent changes from interactions or new data | Poisoning and backdoor-trigger injection |
Select the closest primary pattern, then document secondary characteristics. A system may combine patterns; the selector is an analytical starting point, not a forced taxonomy.
Trust-boundary worksheet
Section titled “Trust-boundary worksheet”For every boundary, capture:
| Field | Question |
|---|---|
| Source | Who or what initiates the flow? |
| Destination | Which component or agent receives it? |
| Data | What content, command, identity or authority crosses? |
| Authentication | How is the source verified? |
| Authorisation | Why is this action permitted? |
| Integrity | How is tampering detected? |
| Confidentiality | How is disclosure prevented? |
| Validation | How is untrusted content handled? |
| Logging | Can the action be attributed and reconstructed? |
| Failure mode | What happens when verification is unavailable or ambiguous? |
Attack-path construction
Section titled “Attack-path construction”A useful scenario is structured as:
Actor or failure → entry point → exploited weakness → trust or privilege transition → affected asset → agent action or system behaviour → business, safety, privacy or mission harm.
Example:
A malicious supplier document enters an automatically indexed knowledge base, embeds hidden instructions, is retrieved by a privileged support agent, causes an unauthorised account action and leaks customer data through an external tool.
This path links Layer 2, Layer 3, Layer 7 and the cross-layer Data Leakage threat.
Minimum viable architecture evidence
Section titled “Minimum viable architecture evidence”Before scoring a complex agentic system, obtain:
- Current architecture or data-flow diagram.
- Component and dependency inventory.
- Model and model-provider details.
- Tool and permission inventory.
- Identity and service-account map.
- Data classification and lineage.
- Network and deployment diagram.
- Agent goal and policy definitions.
- Logging and monitoring architecture.
- Supplier and external-agent inventory.
Missing architecture information should increase uncertainty, not be silently interpreted as a safe design.
Reassessment triggers
Section titled “Reassessment triggers”Repeat decomposition when:
- A model or provider changes.
- New data or RAG sources are added.
- A tool gains broader permissions.
- Autonomy increases.
- A system enters production or a new jurisdiction.
- An agent begins interacting with other agents.
- Persistent memory or self-learning is introduced.
- A major framework, infrastructure or supplier dependency changes.
- An incident exposes an undocumented path.