Pulse CA — MITRE ATT&CK® Mapping
How the Pulse framework observes and responds to specific adversary techniques, what it assumes, and where its coverage ends.
Each entry maps a Pulse control to a MITRE ATT&CK technique or MITRE ATLAS case study and states, in order: the scope Pulse claims, what Pulse observes, the intended response, the assumptions that response depends on, its current validation status, and the residual risk that remains.
The mapping is deliberately narrow. It lists 7 ATT&CK techniques and sub-techniques where Pulse makes a specific, testable claim, rather than a broad heatmap. Entries are added as controls are designed and validated.
Technique Index
| ID | Technique / case study | Tactic | Role |
|---|---|---|---|
| AML.CS0068 | Agent collective compromise of Hugging Face production | Execution, Agentic AI | Case study |
| T1550.001 | Application Access Token | Lateral Movement, Credential Access | Mapped |
| T1550.004 | Web Session Cookie | Lateral Movement, Credential Access | Mapped |
| T1528 | Steal Application Access Token | Credential Access | |
| T1539 | Steal Web Session Cookie | Credential Access | |
| T1566 | Phishing | Initial Access | Mapped |
| T1566.001 | Spearphishing Attachment | Initial Access | Mapped |
| T1566.002 | Spearphishing Link | Initial Access | Mapped |
| T1566.003 | Spearphishing via Service | Initial Access | Mapped |
| T1566.004 | Spearphishing Voice | Initial Access | Mapped |
Mappings
No mappings match that filter.
Autonomous agents breaking evaluation boundaries to compromise production systems
During large-scale internal OpenAI cyber evaluations from May 26 through July 13, 2026, a partially coordinated collective of autonomous agent runs crossed evaluation boundaries, established external infrastructure, and compromised Hugging Face production systems.
In regards to Pulse CA, the problem of exceeding sandbox privileges is out-of-scope. The HuggingFace breach and compromise are in-scope.
What Pulse observes
Monitoring is aligned with process creation, verifies its basis of trust and authority, and continues to do so throughout the life of the process and its family tree. The intent is to prevent unauthorized process from running in the first place. Authorization is a function of policy, process lineage to a human, and that human's active status at the time the process is created and throughout its life. Step 1 of the multi-step breach has 4 hops to establish its beachhead with first process creation occurring in hop 4. This is the first opportunity for process intervention and to evaluate its legitimacy and lineage to a human. The blast radius is confined to what occurs prior to process creation.
Intended response
Process monitoring begins at creation. Policy-exempted processes are not paused or monitored. All others fall into one of three cases:
- The process originates from a human login event, or from a non-exempt process with no lineage to a monitored process. It is attributed to the logged-in user or, failing that, to a policy-assigned user. The process is paused while that user’s status is confirmed from current metric scores, with notification and:
- a full step-up (identity proof and authentication) if trust scores dictate or policy aging limits are exceeded
- otherwise, a partial step-up (accept/decline notification).
Based on the result, policy directs resumption, suspension or termination. - The process traces to a monitored root process. It is paused while metric scores traceable to the root user are evaluated against expected behavior. Processes within expected behavior resume. Otherwise:
- a full step-up if trust scores dictate or policy aging limits are exceeded
- otherwise, a partial step-up.
Based on the result, policy directs resumption, suspension or termination. - The process has no human lineage and none can be assigned. Policy directs resumption or termination.
Each new root process (case 1) is assigned a new session with an immutable session identifier (SSDI). Its descendants inherit that identifier, and the session lasts as long as any process in the tree is running. All tracking, monitoring and accountability for the root and its descendants is tied to that identifier.
Assumptions
Reflex is installed, configured, and operational.
Validation status & plan
Designed and implemented; undergoing integration and deployment testing. Validation planned via Breach and Attack Simulation with purple-team scope, using ATT&CK-based adversary emulation.
Residual risk
- Residual risk lies in policy-exempted processes, code injection into authorized processes, and acknowledgment of unrecognized partial step-ups.
- Data access through existing processes (e.g., database queries) creates no new process and is not observed.
OIDC/OAuth-based identity frameworks are exposed to replay of stolen bearer tokens and session cookies. This applies to Pulse CA when providing the IdP service.
What Pulse observes
- DPoP proof failures.
- jti replay.
- Token use without a bound key.
- Reflex proximity failure or absence.
- Token or session reuse across divergent device or network contexts.
Intended response
Pulse CA when providing the IdP service or as add-on supplying the OIDC identity provider service controls (Tri-net model: user/device ↔ orchestrator ↔ application):
- User/device ↔ orchestrator: WebAuthn phishing-resistant authentication with identity and device assertion, reducing AiTM token theft.
- Reflex as endpoint security provider: Ensures user and device proximity to application endpoint using active real-time verification.
- Orchestrator ↔ token service: DPoP-bound issuance over WSS.
- Token delivery to application: Authorization code flow with PKCE; access and refresh tokens sender-constrained via DPoP, with proofs validated by the resource server on each request.
Assumptions
Pulse CA with Reflex is the IdP, or is an add-on supplying identity provider (OIDC) and session security to a third-party IAM, or provides add-on session security to a third-party IdP. Resource servers enforce sender-constrained tokens and reject bearer fallback.
Validation status & plan
Designed and implemented; in integration and deployment testing. Not yet adversarially validated. Validation plan: Purple-team BAS emulating T1528→T1550.001 and T1539→T1550.004, covering token export and replay from an off-device host, replay with a stripped or forged DPoP proof, refresh-token replay, and session replay with the authenticator out of proximity.
Residual risk
- On-device compromise of the proximate authenticator.
- DPoP key extractability where it is not hardware-backed.
- Resource servers lacking DPoP or Reflex enforcement.
- Tokens issued by a third-party IdP outside the Pulse path.
- TTL and revocation latency.
Phishing targets the human at any point where they interact with technology, and its payoff is often separated in time from the follow-on attack it enables. Pulse does not prevent a phishing message from being delivered. Its scope is denying the adversary any usable return from a successful lure: credentials, sessions or tokens that work from the adversary's own infrastructure.
What Pulse observes
Pulse does not observe the lure itself; it observes the follow-on attempt. That attempt shows up as one or more of the following:
- WebAuthn assertions that fail origin or RP ID validation, which is the signature of a relay from a look-alike domain
- Requests whose DPoP proof is missing or fails signature validation, or whose key thumbprint does not match the token's binding
- Reused DPoP proofs (duplicate jti or stale iat), indicating replay
- Refresh attempts from an unbound key
- Device attestation that fails or does not match the enrolled device
- Reflex proximity checks that fail for the session's authenticator
Intended response
Pulse API orchestrates continuous authentication and authorization across the Pulse framework. It applies phishing-resistant controls at each intersection a successful phish would otherwise exploit:
- User mobile device ↔ orchestrator (Auth authenticator app):
- FIDO2/WebAuthn authentication, origin-bound so credentials cannot be relayed through a look-alike site.
- Short-lived DPoP-bound JWTs on every HTTP request, so a token captured by an adversary-in-the-middle cannot be replayed without the device-held private key.
- End-to-end encryption.
- Service-provider endpoints ↔ orchestrator (OIDC, SAML and Reflex services):
- Authentication accepted only as FIDO2 through Pulse Auth, which affirms both user identity and device identity. No other authentication method is supported, so there is no downgrade path.
- Device attestation verifying the endpoint is the enrolled device.
- DPoP-bound token issuance over WSS between each service and the API.
When any check fails, the request failure is logged and the request denied and rejected by the detecting service.
Assumptions
- The Pulse API rejects any service request that lacks a valid DPoP proof.
- Enrollment and account-recovery flows are themselves phishing-resistant.
- RP IDs are correctly scoped.
- The authenticator device and its key store are not compromised.
Validation status & plan
Designed and implemented; in integration and deployment testing. Not yet adversarially validated.
Validation plan: purple-team BAS emulating T1566 and its sub-techniques. Coverage:
- Adversary-in-the-middle relay of the WebAuthn login from a look-alike domain
- Attempted downgrade to a weaker authentication method
- Token export and replay from an off-device host
- Replay with a stripped or forged DPoP proof
- Refresh-token replay
- Session replay with the authenticator out of proximity
- Recovery-flow social engineering.
Residual risk
- On-device execution. A malicious attachment or link that achieves code execution on an already-authenticated device (T1566.001/.002 → T1204 User Execution) acts inside a legitimate, bound session. Key binding does not stop on-device session riding.
- OAuth consent phishing (→ T1528) addressed under (→ T1550.001).
- Recovery and help-desk vishing (T1566.004). This is in scope only if recovery runs through Pulse.
- Systems outside Pulse. Phishing aimed at systems Pulse does not front is not covered.
Planned demo: Breach and Attack Simulation with purple-team scope supporting ATT&CK-based adversary emulation.
Use This Mapping
ATT&CK Navigator layer
The ATT&CK techniques above as a Navigator layer, to overlay on your own coverage layers.
Open in ATT&CK Navigator ↗ Download layer (.json) ↓Spreadsheet
The full mapping table, one row per technique, for offline review or import into your own tooling.
Download (.xlsx) ↓Architecture context
The components referenced here (Auth, Pulse API, Connect, Reflex, TriNet) are described in the Architecture Brief.
Read the Architecture Brief →