Access events and audit evidence

Tunnex exposes two different histories:

• Access Events — observed network allow/deny decisions reported from the gateway data plane; and
• Audit Log — control-plane administrative changes such as creating a rule, enabling enforcement, or revoking an invitation.

One does not replace the other.

Open Access Events.

1. Choose All activity or Denies only.
2. Filter Agent when investigating a managed AI principal.
3. Use the search box for a known source/destination.
4. Read outcome, observation time, flow, protocol/port, and decision evidence.
5. Select the ALLOW, DENY, or DENY_AGG badge for detail.

DENY_AGG represents repeated denials summarized into one record; read the aggregate count instead of assuming one packet.

The detail separates:

• source and destination;
• protocol and port;
• matching rule or deny cause;
• applied policy/config evidence when recorded;
• gateway identity; and
• ingest sequence/time.

Historical gateway/rule labels may not be recorded. Current labels are display context, not proof of their name at event time. Human identity is not inferred from an IP address; an agent identity appears only when the successfully applied gateway policy stamped it.

After enabling or changing enforcement:

1. Generate one planned allowed flow.
2. Generate one planned denied flow.
3. Confirm both appear with the correct source, destination, and port.
4. If the event lacks applied-policy evidence, inspect the gateway’s desired and applied revision before claiming enforcement succeeded.

An absent event can mean no traffic reached the gateway, telemetry is delayed, or the wrong gateway handled it. It is not automatically an allow.

Open Audit Log.

1. Choose Actor or leave Anyone.
2. Enter the exact Action, for example org.zero_trust_enabled.
3. Optionally set From and To.
4. Select Apply.

Use Clear before starting a different investigation; the footer reports the number of active filters.

Select an event row.

Record:

• normalized action;
• human/system actor;
• target kind and identifier;
• timestamp; and
• the event’s recorded detail fields.

An audit row proves the control-plane action was recorded. It does not by itself prove every gateway applied the resulting revision or that an application flow worked.

Export or screenshot only synthetic/redacted material. Never include session cookies, invite/reset links, join tokens, device configs, private keys, SSO/SMTP secrets, machine tokens, or real user/resource names in a public report.

For an incident timeline, preserve original timestamps and identifiers in the authorized case system; do not modify the live deployment merely to make a cleaner screenshot.