How do you prove what an automated job or service account actually did when it talks to your Azure resources?
Non‑human identities, service principals, managed identities, CI/CD agents, and other programmatic actors, are the backbone of modern cloud workloads. They let pipelines spin up databases, push containers, and run health checks without a human at the keyboard. Because they are created and rotated by scripts, they often outlive the code that launched them, and their credentials are stored in vaults or configuration files that multiple teams can read.
An audit trail that records every request, every query, and every response is essential for compliance, incident response, and cost control. Regulators and auditors ask for immutable evidence that shows who accessed what, when, and why. When a human logs in, you can usually tie the session to a user name and a MFA event. When a service principal runs, that link is blurred unless you capture the request at the point where the identity is exercised.
Why audit trail matters for non‑human identity
Without a reliable audit trail, a rogue script can exfiltrate data, delete tables, or spin up expensive resources while the organization remains blind. The problem is amplified on Azure because many services support managed identity, a token that the platform hands to the workload automatically. The token is valid for the lifetime of the VM or container, and any code running inside can use it to call other services. If the token is compromised, every downstream call appears to come from a trusted Azure resource, making forensic analysis difficult.
Most teams rely on Azure Activity Log or resource‑specific logs, but those logs often miss the fine‑grained commands that a database or Kubernetes API receives. A SQL query that filters customer records, a kubectl exec that reads a secret file, or an SSH command that modifies a configuration file may never surface in the platform audit. The result is a gap between what the cloud reports and what actually happened inside the service.
Current state: direct connections without central visibility
In many organizations, a service principal is granted a role that spans multiple subscriptions or resource groups. The principal’s credentials are stored in a secret store, and developers embed the secret in CI pipelines. When the pipeline runs, the job connects straight to the target, PostgreSQL, Kubernetes, or an SSH host, using the credential. The connection bypasses any intermediary that could inspect or record the traffic. The setup provides the needed access, but it leaves three critical gaps:
- There is no single point where you can enforce masking or block dangerous commands.
- The request reaches the target directly, so the platform cannot attach its own audit events.
- Even if the target logs the request, the log does not include the originating identity in a way that ties back to the service principal.
These gaps mean the audit trail is incomplete, and you cannot prove that a particular automated job performed a specific action.
Where enforcement must happen: the data path
The only reliable way to capture a complete audit trail is to place a guard at the protocol layer, between the identity and the resource. That guard must inspect every packet, record the request and response, and optionally mask sensitive fields before they reach the client. It also needs to enforce just‑in‑time approvals for risky operations. Because the guard sits in the data path, it can guarantee that no request bypasses logging or policy checks.