OWASP / OWASP/browser-security-project

[V7.4] Add requirement that agent action logs distinguish "no action taken" from "action not recorded," and identify self-reported entries

Open
#4 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
HTML
Stars
5
Forks
1
PR merge metrics
No merged PRs in 30d

Description

Summary

7.4.2 requires that sanctioned AI browsing features "log actions taken and data accessed sufficiently to support incident investigation." The only party positioned to write that log is the agent's own runtime, and the requirement does not say what the log must show when an action was attempted and failed, was never taken, or could not be recorded. As written, an empty log and a missing log are the same evidence.

Problem

  • "Sufficiently" has no test. An auditor asked for evidence under 7.4.2 receives a log produced by the feature being audited, with no way to tell whether a quiet period means no agent activity or unrecorded agent activity.
  • This repo has already settled the same distinction for inventory. The thread on #3 concluded that an enumeration must report "not observed" separately from "no definitions present," because an inventory that cannot fail loudly is not evidence. Nothing applies that rule to action logs.
  • Two adjacent documents already handle it. The OWASP Agent Control Standard requires every step that proceeds without a control decision to be recorded as an audit event (Instrument spec §6.4), and its reference implementation refuses the action when the audit entry cannot be written. NIST draft SP 1353 labels AI-produced mappings "proposed" or "derived" until a qualified human validates them.
  • One observation from outside the browser. In evaluation work I ran on a tool-using agent (self-hosted model behind a reverse proxy, not a managed browser fleet), the runtime's own record was wrong in both directions: of 12 answers logged as empty, 3 were the proxy's error page stored as the agent's output and 9 were the harness storing the last tool result. My own instrumentation emitted 1 of 4 recovery events. Not a browser and not a fleet, so I offer it as the failure shape, not as a rate. It is the shape 7.4.2 cannot currently detect.
  • V8 does not mention agent actions anywhere. 8.1.1's event list, 8.2.3's playbook scenarios, 8.3.1's forensic artifacts, and 8.4.1's metrics all predate agentic features, so the 7.4.2 log has no defined collection path in the chapter that collects logs.

Proposed addition

BSVS-7.4.4 (Level 2, consistent with 7.4.2):

Verify that agent action logs record attempted actions that failed or were blocked, distinguish "no action taken" from "action not recorded," and identify entries produced solely by the agent runtime as self-reported where no independent source (browser, proxy, identity provider, or application log) corroborates them.

Evidence an auditor can request: a controlled test with three agent actions, one completed, one blocked at a confirmation gate, and one with logging made unavailable. The three must be distinguishable in the resulting record.

Related, possibly a separate issue: add agent-initiated actions to the 8.1.1 event list and an agent-performed-action scenario to 8.2.3.

Scope clarification

Not a duplicate of 7.4.2: that requires the log to exist; this specifies what it must show when the logged thing did not happen or could not be written. Not a duplicate of 7.2.3: that separates agent sessions from human ones; this is about completeness and provenance of the agent's own action record. Not a duplicate of #3: that covers what an agent can invoke; this covers what it did.

Suggested mapping

CWE-778 (Insufficient Logging); CWE-223 (Omission of Security-relevant Information). NIST CSF 2.0 DE.CM. Open to maintainer input on the closer fit.

Happy to submit a PR with the exact wording if the direction is agreed.

Prem Methuku

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with BSVS-7.4.2 and compare the inventory distinction from issue #3, then review the referenced 8.1.1, 8.2.3, 8.3.1, and 8.4.1 sections. Done means an agreed BSVS-7.4.4 requirement and evidence showing completed, blocked, and unrecordable actions are distinguishable, with self-reported entries identified.

Written by the indexing model from the issue text.

Assessment

Domain
documentation, security
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.