Audit logging for AI coding agents on Entra

When an AI coding agent writes or modifies production code without reliable audit logging, a single mistake can cascade into downtime, data loss, or regulatory exposure. The cost of investigating an undocumented change often exceeds the effort required to capture the event in the first place. In environments where Entra supplies non‑human identities to AI agents, the gap widens: the token proves identity to the target system, but the target itself rarely records the agent’s intent or the exact commands issued.

Audit logging, therefore, becomes a non‑negotiable control. It must capture every request, the identity behind it, the exact query or command, and the response metadata. The log must be tamper‑evident, searchable, and retained long enough to satisfy incident response and compliance investigations.. Only then can a security team answer questions such as “Did the AI agent read sensitive tables?” or “Was a privileged command approved before execution?”

Why the gateway matters for audit logging

The first piece of the puzzle is the Entra‑issued token. This token tells the downstream service who is calling, but it does not enforce any guardrails. The token alone cannot block a dangerous command, request human approval, or write a session record. Those enforcement outcomes require a component that sits between the identity and the infrastructure.

That component is the data‑path gateway. By placing a Layer 7 proxy in front of the target, the gateway can inspect each protocol message, apply policies, and generate audit records before the request ever reaches the database, Kubernetes API, or SSH daemon. Without the gateway, audit logging would have to rely on the target’s native logs, which often omit the fine‑grained context needed for AI‑driven actions.

How to achieve audit logging with Entra identities

1. Provision a non‑human identity in Entra. Create a service principal or application that represents the AI coding agent. Assign it only the minimal roles required for the tasks it will perform. This step defines who the request is, but it does not enforce any policy.

2. Configure the gateway to trust Entra tokens. The gateway validates the OIDC token, extracts group membership, and maps those groups to policy decisions. This ensures that only authorized Entra identities can reach the protected resource.

3. Register the target resource with the gateway. Whether the AI agent talks to a PostgreSQL instance, a Kubernetes cluster, or an SSH host, the gateway holds the credential needed to reach the resource. The agent never sees the secret; the gateway presents it on behalf of the request.

4. Enable session recording and audit logging in the gateway. Once the request passes the identity check, the gateway records the full request and response payloads, timestamps, and the Entra identity that originated the call. The gateway writes these records to a durable store that is independent of the target system.

5. Define retention and access policies for the audit store. The logs are retained according to your organization’s policy and are only readable by authorized auditors. Because the gateway owns the log pipeline, you can enforce just‑in‑time access to the logs themselves.

With this flow, audit logging is guaranteed by the gateway, not by the downstream service. If the gateway were removed, the Entra token would still allow the AI agent to connect, but no unified, tamper‑evident audit trail would be produced.

Key benefits of gateway‑driven audit logging

• Unified view. All AI‑initiated activity across databases, Kubernetes, and SSH is captured in a single, searchable audit repository.
• Policy enforcement at the point of entry. The gateway can reject a request before it reaches the target, ensuring that only approved commands are executed.
• Separation of duties. Identity provisioning in Entra remains the responsibility of the IAM team, while audit enforcement lives in the gateway, preventing accidental policy bypass.
• Compliance readiness. The audit trail generated by the gateway satisfies evidence requirements for standards that demand per‑user, per‑action logging.

Getting started

To put this architecture into practice, start with the getting‑started guide. It walks you through deploying the gateway, registering an Entra service principal, and enabling session recording. The learn section provides deeper coverage of audit‑logging policies, retention settings, and how to query the log store.

Frequently asked questions

Does the gateway store the Entra token?

No. The gateway only validates the token at request time. It never persists the token, ensuring that credential leakage cannot occur downstream.

Can I retroactively add audit logging to an existing AI workflow?

Yes. By routing the existing workflow through the gateway, you instantly gain session recording and audit logging without changing the AI agent’s code.

What happens if the gateway is unavailable?

Requests are denied because the gateway is the sole path to the target. This fail‑closed behavior prevents unaudited access.

Next steps

Review the open‑source implementation on GitHub to understand how the audit pipeline is built and to contribute improvements: https://github.com/hoophq/hoop.