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

Enumerate CloudTrail trails and event selectors
Enumerate candidate S3 buckets and collect metadata
User: review candidate buckets and approve selection

2. Configuration

Add S3 data event selectors to selected trails
Create or configure new trail for S3 data events (if requested)

3. Validation

Confirm EventSelectors and verify S3 data event delivery

1 Credits

Enable CloudTrail S3 Data Events

Overview

Enable CloudTrail S3 data event logging (read/write) for selected buckets so object-level S3 activity is captured for auditing and incident response. The process evaluates your existing trails and buckets, guides you through selecting which buckets to monitor (including approval for cross-account targets), applies or creates the necessary CloudTrail EventSelectors to capture S3 object events, and then validates that the configuration is persisted and that data events are appearing in delivered CloudTrail logs. The workflow captures machine-readable inventories, approval records, change/audit logs, and remediation guidance for any blockers encountered.

Execution Details

Assessment — enumerate trails and candidate buckets

Enumerate all CloudTrail trails (account- and organization-level) and collect full EventSelector/AdvancedEventSelector JSON plus operational metadata (trail identifiers, regions, LoggingEnabled, IsOrganizationTrail, delivery bucket, last delivery times, tags, and any service-returned tokens). Derive a boolean per trail for whether S3 data events are already present and surface any blockers or governance constraints (e.g., org approval required, missing trail role, non-writable delivery bucket).
Build a candidate S3 bucket list from user-supplied names/ARNs, CloudTrail delivery buckets, and tag-based matches. For each bucket collect identity and security metadata (region, creation date, owner account, tags, encryption/KMS details, versioning, ACLs/policies, block-public-access, lifecycle rules) and attempt non-destructive permission checks where allowed. Cross-reference buckets against existing EventSelectors and flag cross-account buckets or policy denies that would prevent enabling or verification.
Produce machine-readable artifacts: a trails inventory (with s3_data_events_present, readiness flags, blockers and API metadata) and a candidate-bucket mapping that includes recommended DataResource ARN patterns (e.g., arn:aws:s3:::bucket-name/ or prefix-limited patterns), proposed ReadWriteType (ReadOnly/WriteOnly/All) with rationale, permission-check results, and remediation items.

User review and selection — gather approvals and configuration choices

Present the consolidated trail inventory, full EventSelector state, and candidate-bucket mapping so you can review proposed DataResource ARNs and ReadWriteType choices and see permission or policy blockers.
Collect explicit user selections: which exact bucket ARNs to enable, desired ReadWriteType per bucket, and for each selection how to target trails (update specific existing TrailARN(s) or create new trail(s)). For new-trail requests collect TrailName, delivery bucket, multi-region/organization preference, SNS topic (optional), tags, and whether logging should start immediately.
Gather operational constraints and approvals: cross-account confirmation or owner approval evidence, maintenance/change windows, ordering constraints, stop-on-error vs continue-on-error preference, retry/remediation behavior, and produce a machine-readable approval record (approver identity, timestamp, selected buckets and ReadWriteType, target TrailARNs or new-trail parameters, and constraints).

Configuration — apply EventSelector updates and create trails if requested

For updates: prepare merged EventSelector payloads per target trail using resourceType "AWS::S3::Object" and precise ARN patterns as approved. Merge new DataResources into existing selectors (unless explicit replacement requested), validate payload shape and service limits, and use concurrency/version tokens where available to avoid overwrites.
Apply updates to target trails, capture API responses and request metadata, and log full change records (prior and new EventSelector JSON, list of added S3 DataResource ARNs, ReadWriteType, request IDs/timestamps, and tokens used). If a per-trail update fails, capture error details and follow user-specified stop/continue policy; include remediation suggestions.
For new trails (if authorized): validate delivery bucket existence and writeability (non-destructive checks), create the trail with the requested delivery configuration, optionally start logging, apply the approved EventSelectors, verify selectors persisted, and record creation audit entries. If delivery bucket checks or creation fail, record exact errors and recommended remediation; do not proceed without required approvals or until delivery bucket issues are resolved unless you explicitly allow proceeding.

Validation — confirm selectors and verify event delivery

Re-retrieve EventSelectors and AdvancedEventSelectors for every modified or created trail to confirm DataResource ARNs and ReadWriteType exactly match the intended configuration, and confirm LoggingEnabled==true where expected.
For each selected bucket attempt to verify S3 data event delivery by listing CloudTrail log objects under the trail’s delivery prefix and inspecting logs for 'AWS::S3::Object' event records that match the bucket/prefix. Capture sample evidence (log object keys, timestamps, sample eventName/eventTime/object key snippets) and all API request IDs/timestamps used to gather evidence.
Produce a machine-readable verification report per trail/bucket pair containing final EventSelector JSON, confirmed DataResource ARNs, ReadWriteType, LoggingEnabled state, collected evidence or absence thereof, and any discrepancy/error details. For items that did not reach the expected state include precise remediation steps (e.g., update bucket policy to allow CloudTrail, adjust delivery bucket, wait for next delivery window) and mark items requiring manual follow-up.

Outputs and auditability

Machine-readable inventories: trails inventory with blockers/readiness flags; candidate-bucket mapping with recommended ARN patterns and remediation items; explicit machine-readable approval record.
Detailed change/audit logs: pre- and post-update EventSelector JSON, API request IDs/timestamps, concurrency tokens used, and per-update success/failure details with remediation suggestions.
Verification report: per trail/bucket evidence of data event delivery (or clear failure details and remediation steps).
Recommendations and next steps for manual follow-up on cross-account approvals, bucket policy/KMS key adjustments, or organizational governance actions needed before or after enabling S3 data event logging.