Install
$ agentstack add skill-skills-il-security-compliance-israeli-privacy-shield ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ● Environment & secrets Used
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Israeli Privacy Shield
Critical Note
This skill provides compliance GUIDANCE. It does not replace legal counsel. Recommend consulting a privacy attorney (orech din specializing in prati'ut) for specific compliance decisions.
Instructions
Step 1: Assess Security Level
The 2017 regulations define three security levels:
| Level | Criteria | Key Requirements | |-------|----------|-----------------| | Basic | { if (!promptOpen) return; function onKey(e: KeyboardEvent) { if (e.key === 'Escape') rejectAll(); } window.addEventListener('keydown', onKey); return () => window.removeEventListener('keydown', onKey); }, [promptOpen, rejectAll]);
### Visual Equal Weight for Reject and Accept
GDPR Recital 42 + multiple DPA enforcement decisions require that Reject and Accept carry equal visual weight. In practice:
- Same button style (both primary, or both outline)
- Same width
- Same position (side by side, not one hidden behind "Customize")
- "Customize" is a third action, not a replacement for "Reject"
```tsx
{dict.rejectAll}
{dict.customize}
{dict.acceptAll}
Gating the Trackers
The consent state must actually prevent non-consented trackers from running. A banner that does not stop scripts is worse than no banner (it creates a paper trail of false compliance).
// components/consent/consent-gated-trackers.tsx
export function ConsentGatedTrackers() {
const { isAllowed } = useConsent();
return (
<>
{isAllowed('analytics') && }
{isAllowed('analytics') && }
{isAllowed('session_replay') && }
);
}
Also gate the client-side trackEvent helper, events emitted before consent is granted should be dropped, not queued:
const ESSENTIAL_EVENTS = new Set([
'consent_banner_shown', 'consent_accepted', 'consent_rejected',
'consent_customized', 'consent_reopened', 'auth_sign_in',
]);
export function trackEvent(event: string, data?: Record) {
if (!ESSENTIAL_EVENTS.has(event) && !window.__consent?.analytics) return;
// ...send to analytics backend
}
The essential-event allowlist is for legally transactional events (the consent choice itself, auth), not a general escape hatch.
Sentry Integration: Two Pieces
Sentry is unusual because Sentry.init() runs in instrumentation-client.ts before React hydrates, which is before useConsent() can tell you what the user wants. Two pieces:
1. Hydrate window.__consent from storage BEFORE Sentry.init(). Without this, any errors thrown during early hydration are captured even if the user previously rejected consent.
// instrumentation-client.ts
import { hydrateWindowFromStorage } from '@/lib/consent/store';
hydrateWindowFromStorage(); // sets window.__consent from localStorage
Sentry.init({
dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
integrations: window.__consent?.session_replay ? [Sentry.replayIntegration()] : [],
beforeSend(event) {
return window.__consent?.error_monitoring ? event : null;
},
});
2. Attach Replay mid-session when the user later grants consent. Don't re-run Sentry.init(), that breaks the existing client. Use Sentry.addIntegration():
// lib/consent/sentry-gate.ts
import * as Sentry from '@sentry/nextjs';
export function enableSentryReplay() {
const client = Sentry.getClient();
if (!client) return;
if (client.getIntegrationByName?.('Replay')) return; // idempotent
Sentry.addIntegration(Sentry.replayIntegration());
}
The React provider calls enableSentryReplay() the first time state.categories.session_replay flips to true. Dynamic-import it so the Replay bundle is not shipped to users who rejected it:
useEffect(() => {
if (state?.categories.session_replay) {
import('./sentry-gate').then((m) => m.enableSentryReplay());
}
}, [state?.categories.session_replay]);
Server Component Gating
Server Components can read the companion cookie directly:
// lib/consent/server.ts
import { cookies } from 'next/headers';
import { CONSENT_COOKIE_NAME } from './store';
export async function isAnalyticsAllowedServerSide(): Promise {
const store = await cookies();
return store.get(CONSENT_COOKIE_NAME)?.value === '1';
}
Use it to gate after() calls that increment analytics counters:
if (await isAnalyticsAllowedServerSide()) {
after(() => incrementBundleViews(slug));
}
Audit Trail
Amendment 13 and GDPR require you to demonstrate consent on demand. Emit five analytics events through your existing pipeline:
consent_banner_shown(first show only)consent_acceptedconsent_rejectedconsent_customizedconsent_reopened(user re-opens from the footer link)
Store them through the same analytics_events pipeline you already have, no new table needed. These are the events the allowlist in trackEvent lets through even when consent is denied, precisely so you have the refusal on record.
See references/consent-banner-implementation.md for complete copy-pasteable code covering the pub-sub store, the ConsentProvider, the banner, the preferences dialog, the tracker gate, and the Sentry hydration hook.
Consent UI Anti-Patterns
Israeli DPA enforcement, GDPR DPAs, and the French CNIL have published repeated guidance on UI patterns that look compliant but are not. Any of these will cost you on enforcement even if the underlying law text is satisfied.
| Anti-pattern | Why it fails | Fix | |-------------|--------------|-----| | Pre-checked boxes for analytics / marketing | Consent must be explicit opt-in. CJEU Planet49 (C-673/17) is the binding precedent. | Default unchecked; user must actively flip the switch. | | "Accept" button styled larger/colored, "Reject" styled as a text link | Fails the equal-weight test. | Same component, same size, same visual prominence. | | "Reject" hidden behind a "Customize" or "Learn more" submenu | Forces extra clicks to refuse, not to accept. | Reject + Accept on the first screen, side by side. | | "By continuing to use the site, you accept cookies" banners | Implicit consent is invalid under GDPR and Amendment 13. | Banner blocks nothing visually, but trackers do not run until explicit choice. | | Cookie wall ("You must accept cookies to read this article") | EDPB guidance treats conditioning service on consent to non-essential cookies as invalid. | Provide full service regardless of the choice; degrade only genuinely analytics-dependent features (e.g. hide a session-replay-powered debug button). | | Single "Accept all" with no granular option on the first screen | GDPR Article 7(2) requires granularity for distinct purposes. | Either expose the per-category toggles on the first screen, or ensure "Customize" reaches them in one click. | | Re-prompting every session | Consent fatigue, treated by DPAs as a dark pattern. | Re-prompt only on CONSENT_VERSION bump or after 12 months. | | Burying the "withdraw consent" path | Amendment 13 Article 8C + GDPR Article 7(3) require withdrawal to be as easy as granting. | "Privacy preferences" link in the footer that opens the same dialog. | | Storing a consent cookie without an expiry / with multi-year TTL | User has not re-consented; stale consent is no consent. | 12-month max. Bump CONSENT_VERSION whenever you add a tracker. | | Loading the analytics SDK script and calling it with consent=denied instead of not loading it | Loading itself is a data transfer (IP, UA, referer). | Gate the `` tag, not just the SDK's internal flag. |
The banner you ship is one layer. The other layers, a published privacy policy in Hebrew, a named Privacy Protection Officer where required under Amendment 13, a data subject request handling process, a breach response plan, and the database registration for public bodies and data brokers, all have to exist independently. No consent UI substitutes for those.
Gotchas
- Amendment 13 took effect on August 14, 2025 and is live law, not a pending proposal. Agents trained on pre-2025 data may treat Amendment 13 as a future change or miss it entirely. Always assume it applies when advising on Israeli privacy compliance today.
- Amendment 13 expands "personal data" to include IP addresses, geolocation, and online identifiers. This pulls standard web analytics and mobile telemetry into scope. Agents may still apply the older narrower definition and underestimate what counts as personal data.
- Administrative fines under Amendment 13 can reach ~NIS 3.2 million (capped at 5% of annual turnover in the worst cases), plus Section 29A statutory damages up to NIS 50,000 without proof of harm (NIS 100,000 only with intent to harm) and criminal liability.
- Israel does NOT have a GDPR-style 72-hour breach deadline. Under the Data Security Regulations (2017, predating Amendment 13), a "Severe Security Incident" is reported to the PPA "immediately" (miyad) on discovery, and the PPA may direct notifying affected data subjects. Agents often wrongly import GDPR's 72-hour rule, do not.
- Israeli Privacy Protection Law predates GDPR (1981 vs 2016) and still has key differences even after Amendment 13: a narrower right to erasure, and database registration still exists (though narrowed to public bodies and data brokers, plus a separate 100,000-record especially-sensitive notification tier). Agents may incorrectly apply GDPR rules to Israeli contexts.
- Israel has an EU adequacy decision, meaning data transfers FROM Israel TO the EU are generally straightforward. Agents may incorrectly flag Israel-to-EU transfers as requiring additional safeguards.
- The 2017 Security Regulations define three security levels (basic/medium/high) based on record count and data sensitivity. Agents may apply a one-size-fits-all approach instead of the tiered model.
- Penalties under Israeli privacy law include criminal liability (up to 5 years imprisonment) in addition to administrative fines. Agents may understate the severity by comparing only to GDPR's monetary penalties.
Troubleshooting
Error: "Unsure about security level"
Cause: Borderline case between basic/medium/high Solution: When in doubt, apply the higher level. The cost difference is small compared to non-compliance risk.
Error: "Borderline DPO appointment threshold"
Cause: The 10,000-individual threshold for the data-broker DPO trigger is a count of distinct individuals in the database, but the legal text is silent on counting methodology (active vs historical accounts, deduplicated identities vs raw rows, multi-database aggregation). Solution: Count distinct individuals across all linked databases under the same controller, including historical records you have not purged. When the count is near the threshold, appoint a DPO defensively; the cost of appointing is low compared to the cost of an enforcement finding that you were over-threshold and unrepresented. Document the counting methodology so a PPA inspector can audit it.
Error: "Cross-border transfer to a country without an adequacy decision"
Cause: The destination country (US, India, Singapore, most non-EU jurisdictions) does not have PPA-recognized adequate protection, so the default ban on transfer applies. Solution: Pick the strongest available alternative basis in this order: (1) controller-to-controller or controller-to-processor data transfer agreement with privacy obligations equivalent to Israeli law (Israeli equivalent of GDPR SCCs), (2) explicit informed consent of the data subject naming the destination country and the risks, (3) statutory exception (contract performance, legal proceedings, vital interests). Do NOT rely on "legitimate interest" alone for cross-border transfer; the PPA reads that exception narrowly. Document the basis in the data inventory.
Reference Links
| Source | URL | What to check | |---|---|---| | Privacy Protection Authority (gov.il) | https://www.gov.il/en/departments/theprivacyprotectionauthority | Enforcement, database registration and notification, guidance | | Amendment 13 page (gov.il) | https://www.gov.il/he/pages/13amendment | Overview of the reform and its obligations | | Amendment 13 professional guide (gov.il) | https://www.gov.il/he/pages/guidetikon13professional | Detailed implementation guidance for controllers and processors | | Amendment 13 FAQ (gov.il) | https://www.gov.il/he/pages/tikun13qa | Common questions on registration, DPO, breach reporting | | Protection of Privacy Law, 5741-1981 | https://www.gov.il/he/pages/theprivacyprotectionlaw | Primary statute text |
gov.il pages may return HTTP 403 to automated clients; open them in a browser.
Recommended MCP Servers
israel-lawMCP, surfaces Israeli primary legislation and regulations (including the Protection of Privacy Law and related regulations). Use it to pull the current statutory text when a compliance question turns on exact wording. Verify the live gov.il pages above for PPA guidance and forms, which an MCP statute index does not cover.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: skills-il
- Source: skills-il/security-compliance
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.