What information can the system reach?
Trace sensitive data, retrieval sources, user permissions, and provider processing. Check whether access is appropriate to the person and the task.
AI SECURITY & ARCHITECTURE
Useful AI.
Deliberate boundaries.
Work through what an AI system can access, what it can do, and how people will remain in control. Bring security into solution decisions before new capabilities become new exposure.
Discuss an AI security needFor teams designing an AI-enabled product, integrating an assistant with business systems, reviewing existing AI use, or assessing an application before broader adoption.
THE QUESTIONS THAT MATTER
Start with
the real problem.
Define the decision you need to make and the evidence that would help. The engagement should serve that purpose.
What actions can it take?
Examine tool permissions, connected APIs, credentials, approval steps, and the consequences of an incorrect or manipulated instruction.
How are failures handled?
Consider misleading output, prompt injection, data leakage, unreliable dependencies, and where a human should review, intervene, or stop an action.
HOW AN ENGAGEMENT WORKS
A clear scope.
A practical path.
The depth and deliverables depend on the agreed question, available access, and constraints.
- 01
Map the proposed or existing system.
Understand users, objectives, model/provider choices, data flows, integrations, and decisions. Define the components and questions in scope.
- 02
Identify risks and assumptions.
Explore trust boundaries, data sensitivity, identity and authorization, instruction handling, tool access, and oversight. Distinguish a design assumption from something that has been tested.
- 03
Review or design safeguards.
Work through least-privilege access, separation of responsibilities, validation, approval points, observability, and failure handling appropriate to the intended use.
- 04
Turn findings into decisions.
Explain priorities, trade-offs, and further validation needs. Scope an application assessment or penetration test separately where hands-on evidence is needed.
POTENTIAL OUTPUTS
Something your
team can use.
These are examples of engagement outputs. The written scope confirms what is included.
Data-flow and architecture review
A documented view of relevant components, access paths, assumptions, and trust boundaries.
Prioritized risk findings
Risks and recommendations tied to the intended use, affected information, and potential actions.
Secure solution options
Design changes, evaluation needs, and a practical plan for addressing the agreed questions.
ILLUSTRATIVE QUESTION / NOT A CLIENT CASE STUDY
“Can our assistant safely connect to internal tools?”
An illustrative review could follow an assistant from user identity through retrieved documents to an MCP-connected tool. The important questions include whose permissions are used, which data can cross a boundary, what an untrusted instruction could influence, and which actions need human approval. The review scope determines whether those assumptions are examined through architecture analysis, testing, or both.
SCOPE & EXPECTATIONS
Clear boundaries
help good work.
Architecture advice does not certify a system as secure or compliant. The depth of testing, targets, permitted techniques, evidence handling, remediation review, and any follow-up validation must be agreed. A dedicated penetration test has its own authorization and scope.
USEFUL FOR THE FIRST CONVERSATION
- A high-level architecture or description of the intended AI use.
- The data sources, tools, users, and actions involved.
- Known concerns, release decisions, or findings you want to investigate.
BEFORE WE BEGIN
A few practical
questions.
Can you review an existing AI application?+
Yes. Scope can focus on a current design, its data and access boundaries, specific risks, or an agreed assessment. The inputs and access needed depend on the questions being investigated.
Does this cover LLM and MCP integrations?+
Those are relevant technical domains. The engagement can examine model inputs and outputs, retrieval, connected tools, permissions, and approval boundaries. Specific components and testing are agreed rather than assumed.
Is this a compliance assessment?+
No compliance certification or regulatory conclusion is implied. Legal or regulatory requirements should be identified with the appropriate advisers and translated into the agreed technical questions.
How is this different from a penetration test?+
Architecture consulting examines design choices, assumptions, and safeguards. A penetration test seeks hands-on evidence against authorized targets. They can inform one another but have different scopes and deliverables.
YOUR NEXT DECISION STARTS HERE