safetynet/docs/controlled-credential-policy.md

# Approved vault credential submission policy

Ordinary autofill only fills a form. It does not authorize sending passwords
through DLP. Administrators can separately enable controlled submission in the
Local password vault section. The new policy defaults off and requires explicit
approved form rules. Human vault unlock remains required. No agent can unlock the
vault or export passwords through this feature.

An approved rule contains metadata only:

```json
{
  "id": "company-login",
  "actionUrl": "https://login.company.example/signin",
  "usernameField": "username",
  "passwordField": "password"
}
```

Use an exact canonical HTTPS action URL, including its path. Queries, fragments,
URL userinfo, wildcard targets and non-HTTPS URLs are rejected. Username and
password field names must be different printable ASCII strings of at most 128
characters. At most 32 rules are permitted; rule identifiers and exact target/field
signatures must be unique. Never enter credential values in the rule editor.

Review the complete changed policy through normal publication. When independent
approval is configured, another authorized administrator must approve it. Auditor
controls remain read-only. Disabling the toggle and publishing revokes permission
once the signed policy reaches the device; pending allowances must recheck policy
before release.

Agent preparation additionally requires `vault:prepare-submit` in the central
baseline and its individual grant. This scope starts unchecked. Its purpose is
to fill and authorize one approved login POST with a human-unlocked vault;
preparation does not itself submit the form. Ordinary `vault:fill` does not grant
this separate permission.

A controlled allowance must be short-lived, single-use and bound to the current
native document, exact POST destination, credential fields/values, verified actor,
policy and vault state. Every other field remains subject to DLP. The approved site receives the filled username and password in its DOM; site
JavaScript can read those values. The lease controls a supported native network
submission and does not isolate passwords from that site. This is not
cryptographic attestation of a webpage's form, proof of website identity or a
phishing guarantee. Do not treat the presence of a password field as an exemption.
Preparation currently expires after 15 seconds and is consumed by one candidate
submission; a mismatched attempt also consumes it. Request bytes are limited to
64 KiB and 128 distinct fields. Do not retry automatically after failure.

Supported submission is a bounded native main-frame POST using standard
`application/x-www-form-urlencoded` bytes. JavaScript fetch/XHR logins, multipart,
JSON and arbitrary login protocols are not covered by this allowance. Unsupported
or ambiguous submissions remain blocked. A subsequent 302-style GET is inspected
as ordinary navigation; a 307/308 redirect that would resend the credential body
must be blocked. The allowance never grants a redirect destination permission.

## Verification status

Schema and admin tests prove defaults, exact URL and field constraints, strict
metadata shape, uniqueness and policy round-trip. Actual Windows/Electron admin publication verifies controlled submission starts
off, reviewed form metadata and the separate preparation scope reach the signed
baseline and individual grant, self-approval is denied, auditor controls are read-only,
and rotation/history restoration follow independent review. Completed API requests
export correlated traces (`artifacts/agent-grants-history-admin-proof.json`).
The isolated Windows/Electron fixture proves approved native POST delivery, safe
302 GET navigation, blocked 307 credential replay, denied residual confidential
data, duplicate credential fields and changed actions, plus vault lock, foreground
swap, central disable and targeted revocation. The trusted human UI handoff is
exercised (`artifacts/controlled-login-native-proof.json`). Terminal completion/
failure audit ingestion and ECS/CEF semantics have separate backend tests; actual
terminal export correlation must be verified against the final native run. These
proofs do not establish compatibility with arbitrary login pages. Ordinary telemetry must contain fixed reasons and event references, never
passwords, usernames, form bodies or secrets.

## Interpreting lifecycle audit

`vault.submission-prepared` means a local, short-lived allowance was issued.
`vault.submission-authorized` means current policy approved the request; it does
not prove bytes reached the destination. `vault.submission-completed` means the
native HTTP transaction finished, including an HTTP error response: it does not
mean website authentication succeeded. `vault.submission.failure` marks a native
transaction failure, and `vault.submission-denied` marks a security refusal.

These events retain only fixed lifecycle names, policy/version and trace linkage.
Passwords, usernames, form IDs, hosts, action URLs and request bodies are not
accepted in vault lifecycle metadata. Analysts can export authenticated ECS/CEF
records. ECS represents transaction failure as an error/failure; CEF retains its
fixed failure action at the existing informational severity 3. Security denial
exports severity 7. Ordinary lifecycle success is not an authentication assertion.

The actual rendered password panel was inspected: Fill login, Prepare approved
login and Delete fit the card without overlap. Native fixture checks show the
preparation button is hidden when centrally disabled, visible when enabled, and
trusted handoff clears master/save fields before webpage focus. The screenshot
uses an isolated synthetic page with its username paragraph hidden for capture;
it does not prove arbitrary webpage layout or secret isolation.


## Credential escape checks and limits

A prepared lease also watches ordinary URL/header requests from its WebContents;
this watch grants no DLP exemption. Public subframe requests retain the lease,
while detected credential leakage consumes it and cancels the request. Header
checks include bounded two-value combinations in both orders so unrelated native
headers do not hide that split. Arbitrary encodings and fragmentation across many
requests are not proven covered. Filled credentials remain accessible to website
JavaScript; this increment is not credential isolation from a malicious page.

The first native split-header regression failed despite passing broker tests.
The failed run is retained in local evidence; a corrected final native run and
new package verification are required before claiming the refinement verified.


The subsequent final native regression now passes both escape cases using a vault
password absent from core DLP rules: GET URL and actual split-header fetch are
canceled, with zero receiver leaks. Native metadata confirms an intervening
Chromium header, false all-values match and true two-fragment match. Common trace
`6709b228cb8ce71a88acc7584a27c5a1` verifies terminal ancestry, inspection and audit
children; original and alternate values are absent from ordinary ECS/OTLP output.
The complete suite passes 668 tests. Final package verification remains separate.


Final stable Windows packaging and exact packaged-source/runtime verification
pass (`artifacts/controlled-login-release-windows-build.log` and
`artifacts/controlled-login-final-package-proof.log`). The executable remains
`NotSigned`; this is not a signed production installer or security certification.


The receiver-strengthened final native run also passes: exactly four approved
credential POSTs, zero public POSTs, zero replays and zero credential URL/header
leaks at the independent HTTPS receiver. It privately checks any two header
fragments rather than relying on all-values concatenation. Current trace
`050f7f44bc009f949c838f8a067649e4` has 101 spans with verified request ancestry;
collector rejected writes remain zero. Evidence: `artifacts/controlled-login-native-proof.json`
and `artifacts/controlled-login-receiver-proof-native.log`. Earlier native failures
and the prior successful proof remain distinct local evidence.