For the complete documentation index, see llms.txt. This page is also available as Markdown.

Session Audit

Capture and trace privileged session activity with full access context

During SOC 2, PCI-DSS, HIPAA, or other compliance audits, your security team may need to prove what occurred during privileged access. Teams can usually show who requested access and who approved it, but proving what happened during that access often requires data from multiple systems.

Without a clear record of that activity, teams gather access requests, approval records, and infrastructure logs from multiple systems, then reconstruct events manually and wait for audit reviewers. This takes time and is difficult to validate. It can leave gaps in audit evidence. In some cases, the next audit cycle begins before the current review is complete. As a result, responding quickly and accurately to compliance requirements becomes more difficult.

Apono’s Session Audit records activity performed during privileged access sessions. When enabled, it captures text-based session activity:

  • Actions performed by real users

  • When those actions occurred

  • Who approved the user's access

  • Which access flow allowed access to the resource

Apono delivers that data into your customer-managed storage for compliance evidence and reporting. Sensitive session data remains under your control and is not persisted in Apono systems.

Scope and limitations

Scope

Session Audit captures privileged session activity through an Apono connector in AWS environments and supports multiple protocols, such as SSH and Kubernetes.

Limitations

Across all protocols, Session Audit does not support the following:

  • Real-time monitoring or alerts

  • Command blocking or enforcement

For protocol-specific limitations, review the Session Audit Reference.


How Session Audit works

When Session Audit is enabled, user connections are routed through the Apono connector instead of connecting directly to the target resource.

Apono works with your existing tools. No proprietary client is required.

Apono does not require developer machines to install a proprietary desktop app or CLI. Users continue working with standard tools such as SSH clients and kubectl, while Apono routes audited sessions through the connector.

The sequence is:

  1. A user is granted privileged access to a resource.

  2. Apono generates access details that route the session through the connector.

  3. The connector proxies the session to the target resource.

  4. The connector captures text-based session activity as the session passes through it.

  5. The connector sends raw session data to customer-managed storage and session metadata to Apono.


Last updated

Was this helpful?