Service
Secure AI Systems on AWS
Independent AWS security and architecture review for organisations running AI systems on AWS — or preparing to. The focus is the AWS posture around AI workloads: IAM, network boundaries, data flow, agent permissions, and the operational controls that determine whether the system is actually safe to run at scale.
The problem
AI systems on AWS rarely fail at the model layer. They fail at the cloud boundary — where agents accumulate permissions, IAM grows faster than anyone can audit, and the blast radius of a compromised role becomes difficult to fully understand.
Common patterns in environments running AI in production:
- IAM roles for agents granted on first principles and never revisited
- Cross-account trust relationships that nobody fully maps
- KMS key policies and resource policies drifting from original intent
- VPC endpoints, egress controls, and data perimeters applied inconsistently across accounts
- CloudTrail and GuardDuty generating signals that nobody meaningfully triages for AI workloads
- Service control policies that have not evolved alongside new AWS services and deployment patterns
The architecture works. The question is whether the AWS posture underneath it is one you can defend — to an auditor, to leadership, or to yourselves after an incident.
Who this is for
Teams running AI workloads on AWS that need an independent, technically deep assessment of the cloud posture underneath them.
- When AI agents are moving into production
- When AWS environments have evolved faster than the security model
- When governance and operational ownership are becoming unclear
- When compliance reviews expose architectural problems rather than documentation gaps
- When leadership needs an independent view of operational and security risk before scaling further
This is a technical review of AWS architecture and operational security posture. If you are earlier in the lifecycle — still evaluating AI architecture direction, delivery readiness, or broader AI operating models — the AI Architecture & Readiness Assessment is usually the better starting point.
Engineer in the loop
This is a deep AWS review, not a checklist exercise.
I use AI agents, graph-based analysis, and automated evidence gathering across AWS environments to investigate at a depth manual review cannot realistically reach within the same timeframe. The objective is not AI-generated findings. The investigation is AI-accelerated. The judgment remains human.
In practice, this means:
- IAM, SCPs, and resource policies are loaded into graph structures and queried for permission paths rather than reviewed role-by-role
- Blast radius for principals — human, service, or agent — is computed across accounts rather than estimated manually
- Evidence is gathered in parallel from IAM Access Analyzer, AWS Config, CloudTrail, Organizations, Security Hub, GuardDuty, and resource inventories
- Findings are validated against the actual architecture rather than pattern-matched from generic benchmarks
The output is grounded in implementation reality, operational constraints, and the actual behaviour of the AWS environment.
Scope
IAM & access architecture
Trust relationships, permission boundaries, SCPs, role assumption chains, identity sprawl, agent and service role design, Access Analyzer findings.
AI workload security posture
AWS controls around GenAI workloads and AI agents, including Bedrock and SageMaker access patterns, secrets handling, API exposure, prompt and output data boundaries.
Network & data architecture
VPC design, workload isolation, VPC endpoints, egress controls, KMS key policies, S3 and resource policies, data movement across accounts.
Multi-account & deployment topology
Organizations structure, account boundaries, infrastructure-as-code maturity, deployment patterns, environment segmentation.
Detection & operational controls
CloudTrail coverage, GuardDuty and Security Hub signal quality, Config rules, auditability, monitoring, and ownership of operational security workflows.
Architectural risk
Fragility, automation gaps, operational bottlenecks, scalability constraints, and AWS service limit considerations.
What you receive
- Executive summary of findings
- Detailed AWS architecture and security assessment
- IAM and trust relationship analysis
- AI workload security posture review
- Prioritised remediation recommendations
- Practical hardening roadmap
- Implementation guidance for engineering and platform teams
The deliverable is written for both engineering leadership and the teams responsible for implementing the changes.
Background
I am an enterprise architect and AI transformation consultant based in Singapore with more than 20 years of experience across cloud architecture, distributed systems, security engineering, and production platform delivery.
My background includes AWS IAM governance, multi-account architecture, infrastructure security, policy automation, DevSecOps, and secure operating models for large-scale cloud environments.
Recent work focuses on secure AI deployment on AWS, AI-agent enablement, architecture automation, and graph-driven analysis approaches for complex cloud environments.
Ready to assess whether your AWS environment is actually ready for AI at scale?
Engagements are scoped to fit the complexity of your environment. Get in touch to discuss your situation.