CloudAgent gives you AI agents that manage your cloud infrastructure. They handle tasks like security compliance, cost optimization, deployments, and monitoring. You remain in control as agents show you their plans, wait for your approval, then execute. Think of it as having a cloud operations team that works 24/7 without needing to hire an army of cloud experts.

How can AI agents be trusted with production cloud infrastructure?

You stay in control through approval workflows where every infrastructure change can require human approval before execution, custom security controls with granular access rules, complete audit trails of every action, self-hosted deployment options, and progressive trust models starting with read-only access.

How does it actually reduce costs?

CloudAgent agents delete unused resources, schedule non-production shutdowns, right-size infrastructure based on usage patterns, and recommend architectural optimizations. Early customers report 15-40% cost reduction within 90 days. Unlike dashboards, CloudAgent actually fixes the problems.

1. Assessment

Discover CloudTrail trails
Gather S3 log-bucket configurations
Inventory candidate KMS keys
User: Select trails and CMK approach

2. Configuration

Create or prepare CMKs
Update S3 bucket policies for KMS-encrypted delivery
Attach CMK to CloudTrail trail

3. Validation

Verify CMK association and encrypted delivery

1 Credits

Configure CloudTrail KMS Encryption for Trails

Overview

Configure CloudTrail trails to use customer-managed KMS keys (CMKs) and ensure the associated S3 buckets and policies permit KMS-encrypted delivery. The plan evaluates existing trails, log buckets, and candidate KMS keys; guides you through selecting which trails to modify and whether to reuse or create CMKs; prepares or creates keys and minimal bucket policy updates as required; attaches the chosen CMKs to the trails; and validates that CloudTrail is writing KMS-encrypted log objects. Every step produces machine‑readable inventories, audit metadata, and explicit user consent records where changes are needed.

Execution Details

Phase: Assessment

Discover CloudTrail trails and collect full metadata per trail (name/ARN, region, multi-region/organization flags, logging status, S3 bucket and prefix, current KmsKeyId/Arn, SNS role/role ARN, insight/data-event settings, tags, creation timestamp). Flag organization-level or multi-account implications and any potential blockers for using a CMK.
Gather S3 log-bucket configuration for each trail: bucket name/ARN/region/owner, default encryption (SSE-S3 or SSE-KMS with key ARN), full bucket policy and ACLs, versioning/object-lock/lifecycle settings, and any policy conditions that would block encrypted writes (e.g., s3:x-amz-server-side-encryption or aws:SourceAccount/SourceArn). Record cross-account relationships and conflicts.
Inventory candidate customer-managed KMS keys: KeyId/Arn, aliases, state, rotation, tags, and full key policy. Evaluate whether each key’s policy grants CloudTrail and relevant principals the required kms actions and identify keys that are unsuitable or need policy changes. Produce suggested policy snippets where necessary.
Produce machine-readable outputs: a trails inventory, a TrailARN→bucket mapping with policy excerpts, a candidate keys inventory with suitability notes, and summary counts plus API call metadata for auditability.
Present a consolidated report of findings to you and collect explicit selections and approvals: which trails to modify, for each trail whether to use an existing CMK (and whether you permit policy changes), create a new CMK (alias, description, tags, rotation preference, extra principals), or defer. Capture constraints (e.g., do not modify organization trails), acceptance of impacts (costs, potential delivery interruption), and an approver-signed machine-readable consent record.

Phase: Configuration

Create or prepare CMKs:
- For approved new keys, create CMKs with the provided alias, description, tags, and rotation setting; verify Enabled state and capture KeyId/KeyArn and API metadata.
- For approved existing keys, prepare and apply minimal key policy updates (or create grants if appropriate) to grant cloudtrail.amazonaws.com kms:GenerateDataKey / kms:Encrypt and any trail IAM principals kms:Decrypt/kms:DescribeKey. Record before/after policy JSON and grant IDs. If key preparation fails, stop further changes for that trail and record errors.
Update S3 bucket policies only where necessary:
- Identify the exact PutObject/PutObjectAcl permissions CloudTrail needs and prepare minimal, scoped policy statements that allow the CloudTrail principal to write while enforcing server-side encryption with the selected CMK (including aws:SourceAccount/SourceArn conditions for cross-account scenarios).
- If a bucket’s default encryption conflicts with the selected CMK, record the conflict and require explicit user approval before changing policies or recommending default-encryption changes.
- Apply authorized policy updates and record prior/updated policy JSON and audit metadata. If updates fail due to denies or IAM restrictions, flag the bucket for manual remediation.
Attach CMK to each selected trail:
- Prepare and apply the update to set the trail’s KmsKeyId/KmsKeyArn, using concurrency/version tokens as needed to avoid overwrites.
- Capture per‑trail audit entries (previous and new KmsKeyId, request IDs, timestamps). If an update fails, record full error details and do not proceed with dependent actions for that trail.

Phase: Validation

Re-fetch and verify configurations:
- Confirm each updated trail’s KmsKeyId/KmsKeyArn matches the intended key and that LoggingEnabled remains as expected.
- Re-check each CMK’s policy to confirm required statements permit cloudtrail.amazonaws.com and relevant principals to call kms:GenerateDataKey and kms:Encrypt.
- Re-check each S3 bucket policy to confirm PutObject/PutObjectAcl permissions are present and that encryption conditions reference the selected CMK where applied.
Inspect S3 delivery evidence:
- List recent objects in each trail bucket, select recent log files, and verify object metadata indicates SSE using AWS-KMS with the expected KeyId (e.g., the KMS key id in object metadata).
Produce a final machine-readable verification report containing, per updated trail: TrailARN and retrieved config, KeyId/Arn and key policy excerpts, bucket name and final policy excerpt, example log object keys with encryption metadata, API request IDs/timestamps, and a summary of resources that did not reach the expected state with exact error messages and recommended remediation steps.

Outputs and Safety Measures

Outputs: comprehensive machine‑readable inventories (trails, buckets, candidate keys), change-audit records (before/after policy JSON, grant IDs, API metadata), user consent records, and a final verification report.
Safety: the workflow requires explicit, recorded user approval before any key creation, key policy change, bucket policy modification, or trail update; it stops applying changes for resources where preparatory steps fail; and it records detailed errors and remediation suggestions for manual follow-up.