Anonymized agentic cloud platform / Production case
Building a Secure Agentic Cloud Operations Platform
An anonymized case study in building a secure, tenant-bound, read-oriented cloud-operations platform where reasoning, typed tools, temporary identity, and cloud authority remain separate.
- 01VerifySigned channel request and OAuth context
- 02ResolveTenant, workspace, account, and conversation
- 03ReasonExplicit LangGraph state and tool policy
- 04ConstrainPrivate typed MCP capability boundary
- 05AssumeShort-lived tenant-scoped cloud identity
- 06ExplainDeterministic evidence and traced response
Operating thesis
The architecture had to make trust visible.
The platform had to let an agent investigate real cloud systems without turning model intent into ambient authority. Authentication established the tenant, LangGraph made reasoning explicit, a private MCP plane constrained capabilities, short-lived roles bounded cloud access, and deterministic calculations preserved evidence the model could explain but not invent.
System architecture
One control path. Explicit boundaries.
Each stage owns a narrow responsibility. Identity, evidence, and operational state travel through the system instead of being reconstructed at the edge.
- 01
Verify
Signed channel request and OAuth context
- 02
Resolve
Tenant, workspace, account, and conversation
- 03
Reason
Explicit LangGraph state and tool policy
- 04
Constrain
Private typed MCP capability boundary
- 05
Assume
Short-lived tenant-scoped cloud identity
- 06
Explain
Deterministic evidence and traced response
Platform primitives
Reusable decisions, not duplicated plumbing.
The platform concentrated difficult cross-cutting concerns into contracts that product and engineering teams could reuse.
Reasoning was not authority
The agent selected information and capabilities; the private tool plane and cloud IAM determined what could actually execute.
- Registered tools only
- Private MCP service
- Cloud IAM as final gate
- No unrestricted shell
Tenant context traveled end to end
Workspace, channel, thread, account, environment, credentials, checkpoints, logs, and traces remained bound to one tenant context.
- Composite thread keys
- Account-scoped tools
- Tenant-tagged traces
- Cross-workspace isolation
Operational evidence stayed deterministic
Code owned periods, baselines, p95 calculations, traffic-aware thresholds, and classifications. The model explained the result.
- Cost periods
- Latency baselines
- Traffic filters
- Stable/watch/attention
Workloads failed independently
Interactive requests, tool execution, scheduled investigation, and notification delivery had different scaling and recovery controls.
- Agent Gateway
- MCP Gateway
- Briefing worker
- Notification worker
Decision record
Trade-offs were part of the design.
The case is useful because the rejected shortcuts and operating constraints are as visible as the chosen technologies.
- 01
Separate the external and private gateways
Authenticate collaboration-channel interactions at the Agent Gateway and expose cloud capabilities only through a separately deployed private MCP service.
- 02
Mint authority only at tool execution
Resolve the tenant and account first, then assume short-lived cross-account roles with external IDs and conservative credential caching.
- 03
Let code calculate and models explain
Keep cost windows, reliability baselines, p95/error calculations, and finding classifications deterministic.
- 04
Split interactive and proactive operations
Run scheduled investigation and notification delivery outside the request path, with durable queues, retries, dead-letter behavior, and bounded concurrency.
- 05
Build once, promote the same digest
Promote immutable images through development, staging, and production with smoke checks and rollback to a known release.
Evidence register
Results keep their denominator.
Reported scale, source-inspected implementation, and bounded validation are deliberately separated.
registered MCP tools
The inspected AWS tool registry covered tenant context, spend, provider documentation, logs, alarms, and metrics.
Python test functions counted
The count spans services, shared libraries, agent code, infrastructure helpers, and adapted tools; it is not a claim that every test was rerun for this case.
delivery workflows in the monorepo
The inspected CI/CD system covered quality, security, build, infrastructure integration, promotion, smoke testing, and rollback paths.
senior engineers enabled
Team leverage is leadership-reported and retained as organizational context rather than independently verified productivity evidence.
06 / Claim boundary
What this case does not claim.
Honest system descriptions separate implemented capability from reported scope, modeled capacity, and future-state architecture.
- 01
The inspected runtime was AWS-first
GCP and Azure existed as provider-neutral contract stubs or reported scope, not as verified tools, credentials, reports, or runtime adapters.
- 02
No closed-loop remediation was verified
Read-oriented investigation and briefings were implemented. Write-capable cloud tools and an approval-to-execution loop were not present in the inspected snapshot.
- 03
Tenant context was not authentication
The MCP tenant header propagated context inside a trusted private boundary; external authentication and service isolation remained separate controls.
- 04
No universal savings, uptime, or certification claim
The case demonstrates architecture and implementation evidence, not a contractual SLO, guaranteed savings percentage, fine-grained per-user cloud RBAC, or independent certification.
Implemented stack
Technology followed the operating model.
The stack is listed as implementation context, not as a substitute for architecture or evidence.
- Python
- LangChain
- LangGraph
- AWS Bedrock
- Langfuse
- FastMCP
- FastAPI
- Pydantic
- PostgreSQL checkpoints
- AWS STS
- EKS Pod Identity
- AWS KMS
- Secrets Manager CSI
- EventBridge
- SQS and DLQ
- DynamoDB
- Amazon EKS
- Terraform
- GitHub Actions
- OIDC delivery
- HPA and PDB
Build the boundary before the feature
Need this level of platform clarity?
Drizzle Systems helps teams turn AI, cloud, and platform ambition into an architecture that can be operated, verified, and handed on.