What native cloud audit logs are for
AWS CloudTrail, GCP Cloud Audit Logs, and Azure Monitor are excellent at recording API calls made to cloud services: who called s3:PutObject, who modified an IAM policy, who spun up an EC2 instance.
These are infrastructure-level events. They're essential for cloud security posture and compliance with frameworks like CIS Benchmarks.
But they don't record what happens inside your application — the business logic layer where the events that matter to your customers and auditors actually occur.
The application layer gap
When an admin in your product grants a billing role to another user, CloudTrail records nothing. When a support agent views a customer's PII record, GCP Cloud Audit Logs has no entry. When your AI agent makes a consequential decision on behalf of a user, Azure Monitor is silent.
These are application-level events. Your code handles them. Your database stores them. And the only audit trail you have is whatever your application code decides to write.
Cloud audit logs answer "what did AWS do?" Application audit logs answer "what did your users and admins do inside your product?" These are different questions. Most compliance frameworks require you to answer both.
The verification gap
Even when cloud audit logs do capture relevant events (e.g., database access via RDS API), they don't provide:
- Application-level context: who in your application triggered the action, not just which AWS principal
- Business logic metadata: the purpose, the affected customer, the reason for the action
- Cross-event chain verification: proof that the sequence of events is complete and unmodified
CloudTrail has log file integrity validation — it signs log files and you can verify the files haven't been modified. But this operates at the file level, not the individual event level. And it requires AWS infrastructure access to verify.
| Feature | unTamper | AWS CloudTrail | GCP Cloud Audit |
|---|---|---|---|
| Application-level events | |||
| Event-level hash verification | |||
| Independent verification (no cloud creds) | |||
| Typed actor/action/target schema | |||
| Infrastructure API call logging | |||
| IAM and identity event logging | |||
| Auditor access without cloud credentials |
The right answer: both
Native cloud audit logs and application audit logs are not substitutes — they're different layers of your security and compliance posture.
Use native cloud audit logs for:
- Infrastructure access patterns (who accessed what cloud resource)
- IAM and identity changes at the cloud level
- Compliance with CIS Benchmarks, AWS Security Hub, etc.
- Detecting cloud-level threats (unusual API call patterns, privilege escalation)
Use unTamper for:
- What happened inside your application — business logic events
- Admin actions, role changes, configuration modifications in your product
- User-visible events that enterprise customers and auditors care about
- Any event where you need to produce verifiable proof that the record is intact
CloudTrail tells you what AWS did. unTamper makes what your application did defensible.