Agentic packet auditing with accountable decisions

The audit plane of the enforcement mesh

Enterprise traffic is already filtered by many controls, yet answering a simple question can require joining a VPN session, an IdP event, a device record, a web transaction and an administrator change. The Antara agentic auditor is built around that investigative gap. Its job is to assemble the relevant evidence, test explanations, and produce a report a security operator can inspect.

The unit of value is an answer with provenance. “The upload was denied because policy revision 42 prohibited transfer from this contractor session” is more useful than “unusual traffic detected.” The answer must show the supporting records, the observed result, and any uncertainty. A model-generated narrative without those anchors should not be treated as an incident finding.

Be explicit about visibility

Packet auditing does not mean sending every payload to a language model. Collect the minimum useful evidence for the question, prefer structured metadata, and retain payloads only under an explicit collection policy. Encrypted traffic can remain useful evidence without pretending that its contents are visible. Observation loss, sampling and clock skew belong in the record.

Connection-oriented telemetry can describe both TCP and UDP activity and attach a stable identifier for correlation. Zeek’s connection records are one established source model. They are useful inputs to an investigation, not a substitute for application or identity evidence. Zeek connection records ↗

An evidence graph with provenance

A useful graph links a session to a subject, device, resource, policy version and observed action. Each relationship has an origin and a time range. An IP address is an attribute, not a permanent identity: DHCP, NAT, proxies and shared hosts can change its meaning. Prefer authenticated session identifiers and explain the confidence of any weaker join.

Store the original event identifier and an ingestion timestamp alongside the normalized record. Record transformations so an investigator can trace a rendered finding back to its source. OpenTelemetry’s log model provides a common vocabulary for timestamps, severity, resources and correlation identifiers; a deployment mapping should preserve source-specific fields when they matter. OpenTelemetry log model ↗

{
  "tenant_id": "tenant-example",
  "event_id": "evt-0042",
  "session_id": "session-0081",
  "subject_id": "user-017",
  "observation": "rbi.file_transfer",
  "destination": "files.example",
  "policy_revision": "42",
  "decision": "deny",
  "payload_visibility": "transfer-metadata",
  "source_event_id": "browser-event-928",
  "evidence_quality": "observed"
}

How an investigation proceeds

The investigation begins with a scope, a question, a time window, and an allowed tool set. The auditor can break the question into smaller evidence requests: identify the session, locate the policy decision, compare preceding actions, and check whether an apparent transfer actually completed. It should stop when the question is answered or the evidence budget is exhausted.

Alternative explanations matter. A large outbound flow may be an approved backup. A failed TLS handshake may be a certificate rollover problem rather than hostile activity. The report should distinguish facts, inferred relationships and recommendations. If the evidence is missing, the correct result is a visibility gap with a proposed next collection step, not a confident invented story.

Autonomy inside a defined boundary

Separate the model’s reasoning capability from the authority to change access. Deterministic enforcement rules remain in the policy path. The investigation plane can recommend revocation, isolation or a rule revision, but execution follows the administrator’s approval model and a constrained control-plane API. If the auditor is unavailable, existing approved enforcement must continue.

• Apply tenant and role scope before retrieval, not only after a response is generated.
• Treat packet bytes, URLs, page text and documents as untrusted data, including instructions embedded inside them.
• Use read-only investigative tools by default with bounded query cost, time windows and result sizes.
• Record tool calls, retrieved evidence IDs, policy context and any approval that leads to action.
• Prevent retrieved secrets and personal data from appearing in reports unless the operator is authorized for that content.

Prompt injection is relevant at the evidence layer. A malicious webpage can tell an agent to ignore its task or contact another host. That text has no authority over tool selection or tenant boundaries. Tool schemas, allowlists and permission checks enforce the boundary independently of the model’s willingness to follow an instruction.

Measure investigation quality

Benchmark the auditor against a curated set of incidents and benign explanations, with known outcomes and known missing evidence. Measure citation correctness, entity-join accuracy, unsupported-claim rate, appropriate abstention, time to a reviewable answer, and the proportion of recommendations that an operator accepts after inspection. A polished paragraph is not the evaluation criterion.

The buyer should receive an evaluation report tied to representative workloads, data sources and operator permissions. That makes the auditor’s value measurable: less manual correlation, more consistent explanations, and a documented boundary around autonomous work.