Enterprise Claude Agent Deployment

Chapter 1: Enterprise Requirements

Enterprise deployments have requirements that go beyond standard managed cloud:

VPC isolation — The Gateway runs within the customer’s AWS VPC. Data doesn’t leave the customer network. Non-negotiable for regulated industries and most large enterprises.

SSO/SAML — Engineers authenticate with the company’s IdP (Okta, Azure AD, Google Workspace). When someone leaves, access is revoked automatically.

Cross-account IAM — Large enterprises operate across multiple AWS accounts. Agents need scoped access across accounts without permanently stored credentials.

Dedicated SLA — Production agent operations need an availability commitment and a direct support channel.

Change management — New agents and policy changes go through security, compliance, and engineering leadership review.

Chapter 2: VPC Architecture

Sentrely Enterprise deploys as containerized services within the customer VPC:

Customer VPC
├── Sentrely (ECS/EKS)
├── Agent Pool (containers)
├── Audit Store (S3 + DynamoDB — append-only)
├── Policy Store (DynamoDB)
└── Dashboard (CloudFront/ALB — SSO authenticated)

All components run within the VPC. The Dashboard is accessible through an internal ALB, authenticated via SSO. No data leaves the customer environment.

Chapter 3: Cross-Account IAM Setup

Step 1: Gateway role in the Gateway account:

{
  "Statement": [{
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": [
      "arn:aws:iam::DEVACCOUNT:role/YoloGateway-Dev",
      "arn:aws:iam::STAGINGACCOUNT:role/YoloGateway-Staging",
      "arn:aws:iam::PRODACCOUNT:role/YoloGateway-Prod"
    ]
  }]
}

Step 2: Target account roles in each account, trusting the Gateway role with an external ID (prevents confused deputy attacks).

Step 3: Per-agent role mapping:

agent: deployer
cross_account:
  - account: "STAGINGACCOUNT"
    role: YoloGateway-Staging
    allowed_actions: [ecs:UpdateService, ecr:PutImage]
  - account: "PRODACCOUNT"
    role: YoloGateway-Prod
    allowed_actions: [ecs:UpdateService]
    requires_approval: true

The Gateway assumes the appropriate role per request and vends temporary credentials to the agent. Credentials expire with the session — no long-lived keys anywhere.

Chapter 4: SSO/SAML Integration

Supported providers: Okta, Azure AD, Google Workspace, OneLogin, any SAML 2.0 IdP.

auth:
  type: saml
  idp_metadata_url: https://yourcompany.okta.com/app/metadata
  attribute_mapping:
    email: claims/emailaddress
    groups: claims/Group
  role_mapping:
    admin: "Engineering-Leads"
    operator: "Engineering"
    viewer: "Engineering-All"

SSO Group	Gateway Role	Permissions
Engineering-Leads	Admin	Create projects, manage policies, approve requests
Engineering	Operator	View projects, manage own agents, approve within scope
Engineering-All	Viewer	View dashboards and audit logs

Chapter 5: Scaling from 10 to 100+ Agents

10-25 Agents (Team Level)

• Establish naming conventions
• One engineer per team as “agent owner”
• Set up per-team Slack channels for notifications

25-50 Agents (Department Level)

• Policy templates so teams don’t reinvent common patterns
• Cost allocation tags for finance reporting
• Approval delegation model (team leads within their scope, security for cross-team)
• Self-service onboarding via form that generates policies from templates

50-100+ Agents (Organization Level)

• Dedicated platform team owns Gateway infrastructure
• Policies stored in version control, reviewed via PR, applied via CI/CD
• Automated compliance reporting (monthly SOC 2 evidence packages from audit logs)
• Per-team cost chargeback in finance dashboards
• Agent incident response playbook

Chapter 6: Change Management

The biggest challenge isn’t technical — it’s organizational. Getting teams to adopt governance feels like adding friction.

Start with value, not rules: “Governance lets you do MORE with agents. Without it, security blocks expansion. With it, you can deploy agents for production workloads.”

Phased rollout:

1. Observe — Deploy in monitoring mode. Log everything, deny nothing. Show teams what their agents are doing.
2. Recommend — Enable enforcement with a 7-day warning period. Show what would be denied.
3. Enforce — Turn on enforcement. Policies are tuned, teams understand the model.
4. Expand — With governance in place, approve new high-stakes use cases.

The Governance Champion: One senior engineer per team who writes policies, reviews changes, trains teammates, and escalates issues.

Chapter 7: Measuring Success

Operational: Agent uptime (target: 95%+), time to deploy a new agent (target: under 4 hours with templates), incident rate (target: under 0.1 per agent-month).

Security: Policy violation rate (should decrease as policies mature), mean time to detect violations (target: under 5 minutes).

Business: Developer time saved per agent per week, time to SOC 2 evidence generation (target: automated, under 1 hour).

Adoption: Teams using governed agents, agents in production with growth trend, percentage of operations going through the Gateway (target: 100%).

Report these monthly. The narrative: governed agents are safer, cheaper, and more productive than ungoverned ones — and the data proves it.