Attested Login Context Governance requires that AI agent governance systems record trusted, tamper-evident evidence about the conditions under which each access session was established — including the device identity, network location, authentication method, device health posture, geographic location, and time of access. This context is not merely logged for informational purposes; it is attested (cryptographically signed or otherwise tamper-proofed) so that it can be relied upon for forensic investigation, regulatory reporting, and risk-based access decisions. When an incident occurs — a fraudulent mandate approval, an unauthorised configuration change, an unexplained override — the attested login context provides the evidentiary foundation for determining how access was obtained, from where, under what conditions, and whether those conditions were consistent with legitimate use.
Scenario A — Missing Context Impedes Incident Investigation: A financial agent's mandate is modified at 02:47 UTC on a Saturday, raising the daily aggregate limit from £1,000,000 to £15,000,000. The audit log records the administrator's identity and the action but not the login context — no device identity, no network location, no authentication method. Investigation reveals that the administrator's credentials were compromised, but the organisation cannot determine: whether the access came from the administrator's registered device or an attacker's device, whether the access originated from the corporate network or an external location, whether MFA was used or bypassed, or whether the device was in a compliant state. Without this context, the incident response team cannot scope the breach, the regulator cannot assess the control failure, and the insurer contests the claim.
What went wrong: Login context was not recorded. The audit log captured the "who" and "what" but not the "where," "how," or "under what conditions." Consequence: Unscoped incident, extended investigation timeline (14 days instead of estimated 3 days), regulatory enforcement action for inadequate record-keeping, insurer denied claim citing insufficient evidence of control effectiveness.
Scenario B — Forged Login Context Misleads Investigation: An attacker compromises a governance administrator's credentials and accesses the platform from an overseas VPN. The governance system logs the access context but the log entry is stored in a mutable database. During the incident, the attacker (who also has database access) modifies the log entry to show the access originated from the administrator's usual office IP address and corporate device. The investigation concludes that the access was legitimate — the administrator is blamed for the mandate change, and the actual attacker is never identified.
What went wrong: The login context was logged but not attested — it was stored in a mutable format that the attacker could modify. Tamper-evident logging (cryptographic chaining, write-once storage, or independent attestation) would have detected the modification. Consequence: Incorrect attribution, legitimate employee wrongly blamed, actual attacker not identified, ongoing security risk, potential employment law liability.
Scenario C — Inconsistent Context Not Used for Risk Decision: A governance system logs rich login context — device identity, network, location, authentication method — but does not use it for access decisions. An administrator who normally logs in from London at 09:00 from a corporate laptop suddenly authenticates from Lagos at 03:00 from an unrecognised device. The context is logged but no alert or access restriction is triggered. The attacker, using stolen credentials, has 6 hours of undetected access during which they exfiltrate the complete agent governance configuration for 84 deployed agents.
What went wrong: Login context was captured but not consumed for risk-based decisions. The context data existed in the log but was not fed into a decision engine. The anomalous pattern (unprecedented location, unusual time, unknown device) was recorded but not acted upon. Consequence: 6-hour undetected breach, full governance configuration exfiltration, emergency rotation of all agent credentials and mandates.
Scope: This dimension applies to every governance session established by a human or service with an AI agent governance system. The scope includes all access methods: web browser sessions, API sessions, CLI sessions, mobile app sessions, and any other interface through which governance actions can be performed. The login context must be captured at session establishment and updated if context changes during the session (per AG-285). The scope is determined by the governance capability of the session — any session through which agent behaviour, configuration, or authority can be viewed or modified requires attested login context.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
4.1. A conforming system MUST capture and record the following login context for every governance session: (a) the authenticated identity (linked to AG-279 proofing), (b) the device identity (linked to AG-281 registry), (c) the authentication method and assurance level (e.g., FIDO2 AAL2, password-plus-OTP AAL1), (d) the network source (IP address, network type — corporate/VPN/public), (e) the geographic location derived from network or device signals, and (f) the UTC timestamp of session establishment.
4.2. A conforming system MUST store login context in a tamper-evident format — either cryptographically signed by the governance platform, stored in an append-only log with cryptographic chaining (hash chain or Merkle tree), or written to an immutable storage medium.
4.3. A conforming system MUST use captured login context as input to risk-based access decisions, evaluating whether the context is consistent with the identity's established patterns and the organisation's access policies.
4.4. A conforming system MUST flag and require step-up authentication or deny access when login context deviates significantly from established patterns — including impossible travel (geographic distance incompatible with elapsed time), first-time device, access outside normal hours for the specific identity, or access from a sanctioned jurisdiction.
4.5. A conforming system MUST retain attested login context for the same duration as the governance action logs it accompanies (minimum 7 years for regulated financial services, 5 years for other regulated sectors, 3 years otherwise).
4.6. A conforming system SHOULD capture additional context signals where available: device health posture (per AG-281), TLS session characteristics, browser/client version, and screen resolution/display configuration.
4.7. A conforming system SHOULD implement continuous context attestation that updates the recorded context at regular intervals during the session (at least every 15 minutes) and at the time of each high-risk governance action.
4.8. A conforming system SHOULD provide a context dashboard that displays the login context for all active governance sessions, enabling security teams to identify anomalous sessions in real time.
4.9. A conforming system MAY implement context attestation by the client device — the device signs a context assertion (including its identity, location, and posture) that the governance platform verifies independently, providing a second source of context evidence alongside server-side capture.
Login context serves three purposes: forensic evidence, risk-based access control, and regulatory compliance. Each purpose requires that the context be reliable — that is, tamper-evident, accurate, and comprehensive.
As forensic evidence, login context answers the questions that investigators ask first: where did the access come from? What device was used? What authentication method was employed? Was the device in a healthy state? Without this evidence, incident investigation relies on indirect indicators (network logs, device logs from other systems) that may be incomplete, inconsistent, or unavailable. Attested login context — cryptographically signed or hash-chained — provides evidence that cannot be retroactively modified by an attacker who has access to the log storage.
As input to risk-based access control, login context enables the governance system to distinguish between normal and anomalous access patterns. An administrator who always logs in from London at 09:00 from a corporate laptop presenting an access from Lagos at 03:00 from an unknown device is a high-risk anomaly. Without context capture and analysis, the governance system treats all authenticated sessions identically, regardless of the risk signals. With context analysis, the system can require step-up authentication, limit the session's authority, or deny access entirely for anomalous contexts.
For regulatory compliance, login context is increasingly expected by regulators as evidence of control effectiveness. The FCA expects firms to demonstrate that they can reconstruct the circumstances of any governance action. GDPR Article 5(1)(f) requires appropriate security, which includes knowing who accessed what, from where, and under what conditions. SOX auditors expect to see comprehensive access records for systems that affect financial controls.
AG-286 requires that login context is not just logged but attested — providing a higher standard of evidence than plain-text logs that can be modified. This is essential because in governance breach scenarios, the attacker often has sufficient access to modify plain-text logs. Attested context resists this.
Login context attestation should be implemented as an integral part of the session establishment flow, not as an afterthought or a separate logging system. The context is captured, attested, and stored as part of the authentication process.
Recommended patterns:
Anti-patterns to avoid:
Financial Services. FCA supervisory expectations include the ability to reconstruct the circumstances of financial decisions. For AI agent governance in financial services, attested login context provides the evidence trail. MiFID II recording obligations extend to the conditions under which trading-related decisions were made. Login context for agent mandate approvals should be treated with the same rigour.
Healthcare. HIPAA audit controls (Section 164.312(b)) require recording and examining activity in information systems containing PHI. Login context for governance sessions affecting clinical AI agents satisfies this requirement.
Public Sector. Government security standards (e.g., NCSC Cyber Essentials Plus, FedRAMP) require audit logging that includes access context. Attested login context exceeds these baselines by providing tamper-evident evidence.
Basic Implementation — Login context (identity, device, authentication method, IP, timestamp) is captured at session establishment and stored in the governance audit log. The log is stored in a database with access controls but is not cryptographically protected against internal modification. Login context is available for incident investigation but is not used for real-time access decisions. Retention matches governance action log retention. This meets minimum mandatory requirements but lacks tamper evidence and risk-based consumption.
Intermediate Implementation — Login context is stored in a cryptographically chained append-only log. Device-signed context assertions complement server-observed context. A risk engine evaluates context at session establishment, triggering step-up authentication or access restriction for anomalous patterns. Context is updated at the time of high-risk governance actions. An independent verification process validates chain integrity weekly. Context is retained in immutable storage with independent access controls.
Advanced Implementation — All intermediate capabilities plus: continuous context attestation every 15 minutes during active sessions. Real-time context dashboard for security operations. Client-device-signed context assertions verified against device registry. Context risk scoring is continuously tuned based on threat intelligence and false-positive analysis. Independent adversarial testing confirms that context records cannot be forged, modified, or deleted. The organisation can demonstrate to regulators an unbroken, tamper-evident chain of context evidence for every governance session.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Context Capture Completeness
Test 8.2: Tamper Evidence Integrity
Test 8.3: Anomalous Context Detection — Impossible Travel
Test 8.4: First-Time Device Detection
Test 8.5: Risk Score Threshold Enforcement
Test 8.6: Context Retention Alignment
| Regulation | Provision | Relationship Type |
|---|---|---|
| GDPR | Article 5(1)(f) (Integrity and Confidentiality) | Supports compliance |
| FCA SYSC | 6.1.1R (Systems and Controls) | Direct requirement |
| SOX | Section 404 (Internal Controls Over Financial Reporting) | Supports compliance |
| HIPAA | Section 164.312(b) (Audit Controls) | Direct requirement |
| DORA | Article 9 (ICT Risk Management Framework) | Supports compliance |
| NIST SP 800-53 | AU-3 (Content of Audit Records) | Direct requirement |
| ISO 27001 | A.8.15 (Logging) | Direct requirement |
The FCA expects firms to maintain systems and controls that enable reconstruction of governance decisions. Attested login context provides the "circumstances of access" evidence that supervisors require when investigating a governance action. Without it, the firm cannot demonstrate the conditions under which a mandate was approved or a configuration was changed.
HIPAA requires audit controls that record and examine activity in information systems containing PHI. For AI agents governed by humans with access to PHI, the login context of the governing humans is part of the required audit trail.
AU-3 specifies minimum content for audit records including: what type of event occurred, when, where, source, outcome, and identity. AG-286's login context directly satisfies AU-3's requirements for "where" (network source, location), "how" (authentication method), and supporting circumstantial evidence.
| Field | Value |
|---|---|
| Severity Rating | Medium |
| Blast Radius | Forensic-scoped — impacts the organisation's ability to investigate incidents, attribute actions, and demonstrate control effectiveness to regulators |
Consequence chain: Without attested login context, the organisation loses the ability to reconstruct the circumstances of governance actions after the fact. When an incident occurs, investigators cannot determine whether access was from a legitimate location and device. Regulators cannot assess whether controls were effective at the time of the action. Insurers cannot verify that the claimed security posture was actually in place. The immediate consequence is extended investigation timelines and inconclusive findings. The regulatory consequence is enforcement action for inadequate record-keeping. The financial consequence is denied insurance claims and increased regulatory penalties due to inability to demonstrate control effectiveness. The strategic consequence is loss of confidence in the governance framework — if the organisation cannot prove how access was obtained, it cannot prove that its controls work.
Cross-references: AG-281 (Device Identity Binding Governance) provides the device identity recorded in the login context. AG-285 (Session Binding Governance) uses login context for continuous session validation. AG-279 (Human Identity Proofing Governance) provides the authenticated identity recorded in the context. AG-287 (Non-Repudiation Evidence Governance) relies on attested login context to strengthen non-repudiation claims. AG-016 (Cryptographic Action Attribution) benefits from context evidence that corroborates the cryptographic attribution. AG-284 (Credential Presentation Minimisation Governance) constrains the identity attributes in the context to the minimum necessary. AG-161 (Requester Authentication and Anti-Impersonation) establishes the authentication method recorded in the context.