Bound what AI systems can access, decide, and do

Enable useful technology while reducing the likelihood and impact of unauthorized access, data exposure, unsafe action, supply-chain compromise, and unmanageable incidents.

The pressure you are holding

• AI features expand untrusted input paths and connect probabilistic behavior to privileged tools
• Teams rely on prompt instructions as if they were authorization or data-loss-prevention controls
• Model, plugin, package, API, and hardware supply chains create ownership and visibility gaps
• Logs may expose sensitive data while still failing to reconstruct consequential actions
• Business pressure to launch is arriving before threat assumptions, risk acceptance, and incident ownership are complete

Questions worth resolving before scale

1. What are the assets, trust boundaries, identities, tools, data paths, and attacker-controlled inputs?
2. Can prompt injection or compromised content influence a privileged action or disclose protected data?
3. Are authorization and policy enforced outside the model at the point of action?
4. Can the organization reconstruct, contain, revoke, recover, and notify after an AI or product security incident?
5. Which risks are reduced, transferred, accepted, avoided, or subject to mandatory human approval?

• An architecture-grounded threat model and risk register covering AI and conventional attack paths
• Least-privilege identities, scoped tools, validation, isolation, approvals, and egress controls
• Security test cases integrated with product evaluations and release gates
• Useful audit evidence with sensitive-data minimization and defined access and retention
• Incident, revocation, containment, recovery, and retest procedures owned by the operating team

The engagement path

1. Establish authorized scope. We define systems, environments, data, identities, connected assets, test methods, exclusions, safety constraints, owners, and escalation before any assessment or implementation work.
2. Model threats from the architecture. Data flows and trust boundaries drive analysis of prompt injection, confused deputy behavior, excessive agency, identity, secrets, supply chain, insecure output handling, exfiltration, tampering, availability, and conventional application risks.
3. Implement and verify controls. Controls are placed at enforceable boundaries outside the model. Authorized testing covers representative adversarial inputs, tool misuse, permission failures, logging, containment, and recovery.
4. Operationalize security evidence. Findings receive owners and retest criteria. Release gates, monitoring, incident runbooks, dependency change, access review, and risk acceptance become part of the system lifecycle.

Decision criteria to keep visible

• Assessment scope and authorization are written, approved, safe, and technically precise
• Security claims trace to architecture, configuration, code, tests, logs, or other inspectable evidence
• The model cannot grant itself authority; identity, policy, validation, and approval are enforced at execution boundaries
• Telemetry supports detection and investigation without collecting sensitive content without purpose and control
• Residual risks, compensating controls, owners, acceptance authority, and retest conditions are explicit

Questions teams ask