01Architecture requirement
Risk-based deployment philosophy
Control depth begins with the workflow, data sensitivity, affected people, action consequence, regulatory context, and plausible failure modes.
Security / production readiness
Security is part of the architecture, not an afterthought.
Keep control of your data and the actions AI can take. We define access, human approvals, and operating responsibilities around your workflow, then select and test the appropriate controls.
Controls matched to the work
Define access, approvals, monitoring, and recovery around the workflow and the people responsible for it.
Risk-based design
The control system begins with consequence.
A knowledge assistant and a system that can change a customer record do not create the same risk. Architecture must reflect what the system can see, decide, change, communicate, and trigger.
Before build, define the authority boundary.
- What data may the system access?
- Which actions are allowed, approval-required, or prohibited?
- When must the system escalate or stop?
- How will failures be detected, investigated, and reversed?
- Who owns production behavior and business policy?
Control areas
Fifteen areas reviewed across architecture and operations.
Status labels clarify whether an item is a standing design requirement, an engagement-specific decision, an operating responsibility, or a current public disclosure.
02Engagement-specific
Data and knowledge boundaries
Approved sources, prohibited data, retrieval scope, retention, and model-provider handling must be defined for the actual deployment.
03Engagement-specific
Identity and access
User, service, and system identities must map to the business roles and environments involved in the workflow.
04Architecture requirement
Least privilege
A deployment should receive only the data and action permissions required for its bounded responsibility.
05Engagement-specific
Tool and action permissions
Allowed, approval-required, and prohibited actions are defined separately instead of treating every connected tool as universally available.
06Architecture requirement
Human approval and escalation
Sensitive, irreversible, low-confidence, policy-exception, or externally binding actions require an appropriate human-control pattern.
07Architecture requirement
Prompt injection and untrusted input
External content, retrieved documents, tool output, and user instructions are treated as untrusted data and cannot redefine system authority.
08Operational requirement
Evaluation and testing
Representative, edge, failure, policy, and regression cases must be evaluated against agreed acceptance criteria before and after material changes.
09Engagement-specific
Logging and observability
Traceability, sensitive-data handling, access to logs, retention, alerting, and review cadence are designed for the workflow and environment.
10Operational requirement
Versioning and rollback
Prompts, policies, code, integrations, evaluation sets, and configuration changes require identifiable versions and an appropriate reversal path.
11Engagement-specific
Incident response
Owners, severity, containment, notification, evidence preservation, recovery, and post-incident review must align with the customer environment.
12Engagement-specific
Data retention
Retention and deletion rules are determined by purpose, sensitivity, legal obligations, provider behavior, and the operating need for traceability.
13Engagement-specific
Vendor and model review
Provider terms, data handling, access, regional requirements, reliability, change behavior, cost, and exit options are reviewed for the proposed use.
14Operational requirement
Customer responsibilities
The customer owns business policy, authorized access, stakeholder decisions, internal adoption, operating coverage, and the accuracy of its source systems.
15Current public status
Control verification
Document the controls, supporting evidence, and review requirements for each deployment.
Design references
Established frameworks. Practical controls.
These resources guide risk assessment, control selection, and testing for each deployment.
NIST
AI Risk Management Framework
A voluntary resource for incorporating trustworthiness considerations into the design, development, use, and evaluation of AI systems.
OWASP
GenAI Security Project
An open-source security initiative documenting risks and mitigations for generative, language-model, and agentic applications.
DESIGN THE BOUNDARY FIRST
Put data, action, human, and operating controls into the Blueprint.
Security requirements belong in the deployment decision and architecture—not in a checklist added after build.
Book a 15-Minute Call