[rodrigojara-cko]

Summary

Security hardening of the authentication client. No public signature changes.

Changes

• src/services/http.js: security hardening of the authentication client
• src/api/access/access.js: security hardening of the authentication client
• src/Checkout.js: initialise the access token holder once per client
• src/api/google-pay/google-pay.js, src/api/onboarding-simulator/onboarding-simulator.js, src/api/tokens/tokens.js: authenticate through the shared path, like the rest of the SDK
• src/api/sessions/sessions.js: per-request headers on a copied config, as cards.updateCard does
• test/http/tokenHandling.js: new unit tests

API Reference

None.

Breaking changes

None to documented usage. config.access is now an empty object before the first OAuth
request instead of undefined; to check for a token, read config.access.token.

Tests

• Existing tests pass (unit suite on Node 18 and Node 20, npm run build)
• Serialization tests cover every new or changed property (no model changes)
• README updated if documented usage changed (no change needed)

Related

None.

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:src/api/sessions/sessions.js
• security_sensitive_path:src/api/tokens/tokens.js
• security_sensitive_path:test/http/tokenHandling.js

Operational gates

• ✅ jira_ticket (INT-1766)
• ✅ independent_review

Files analysed: 7

---

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
security_sensitive_path — src/api/sessions/sessions.js	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — src/api/tokens/tokens.js	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — test/http/tokenHandling.js	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[agent-wall-e]

🟢 Advisory review: Looks good to me

This PR still needs a human approval — wall-e cannot auto-approve it. For what it's worth, I read the diff and found nothing I'd block on.

Security hardening of the OAuth authentication client: fixes token expiry math (seconds→ms), adds a 60s refresh margin, prevents credential leakage in errors, fixes mutation of shared config in sessions.js, and unifies GooglePay/OnboardingSimulator/Tokens to use the standard auth path. The diff matches its stated intent and the changes read as correct.

What I checked

• The old expires_in was stored without ×1000 conversion (treating seconds as ms, expiring ~17 minutes early in wall time); the new storeAccessToken correctly multiplies by 1000.
• The 60-second TOKEN_REFRESH_MARGIN_MS pre-emptive refresh is a reasonable safety margin and doesn't look surprising.
• The isTokenExpired guard now also handles non-Date and NaN values, which correctly forces a refresh instead of silently using a bad token.
• sessions.js now creates a shallow-copied config with the per-request channel header instead of mutating this.config.headers in place, which matches the stated fix and mirrors how cards.updateCard works.
• The storeAccessToken uses Object.assign into a shared config.access object so copies of config (e.g. for sessions) still pick up a freshly stored token — this is intentional and consistent with the comment in the JSDoc.
• Error handling in createAccessToken now throws a plain Error for network failures (no credentials in the message) and dynamically imports ApiTimeout for timeout errors; the dynamic import path is present in the repo so this should resolve correctly.
• The old catch block exposed error.toJSON() (axios serialisation) in thrown objects which could have included request headers/credentials; the new code uses error.response.data for HTTP errors and a simple message string for network errors, which is strictly safer.
• Tests cover token reuse, expiry storage, credential omission, timeout mapping, and the updateAccessToken path — coverage looks adequate for the changed surface.
• The access: {} change in Checkout.js (from undefined) means the truthiness check config.access?.token in httpRequest correctly distinguishes 'no token stored yet' from 'token stored', which is safe.

⚠️ The diff was too large to read in full, so this review covers only part of the change.

---

_{This is not an approval. wall-e cannot auto-approve this PR — it is an opinion to help whoever does. Advisory review · us.anthropic.claude-sonnet-4-6 · wall-e 2026.06.19-02}

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:src/api/sessions/sessions.js
• security_sensitive_path:src/api/tokens/tokens.js
• security_sensitive_path:test/http/tokenHandling.js

Operational gates

• ✅ jira_ticket (INT-1766)
• ✅ independent_review

Files analysed: 7

---

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
security_sensitive_path — src/api/sessions/sessions.js	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — src/api/tokens/tokens.js	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — test/http/tokenHandling.js	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:src/api/sessions/sessions.js
• security_sensitive_path:src/api/tokens/tokens.js
• security_sensitive_path:test/http/tokenHandling.js

Operational gates

• ✅ jira_ticket (INT-1766)
• ✅ independent_review

Files analysed: 8

---

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
security_sensitive_path — src/api/sessions/sessions.js	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — src/api/tokens/tokens.js	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — test/http/tokenHandling.js	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:src/api/sessions/sessions.js
• security_sensitive_path:src/api/tokens/tokens.js
• security_sensitive_path:test/http/tokenHandling.js

Operational gates

• ✅ jira_ticket (INT-1766)
• ✅ independent_review

Files analysed: 8

---

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
security_sensitive_path — src/api/sessions/sessions.js	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — src/api/tokens/tokens.js	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — test/http/tokenHandling.js	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud