Local by default
Risk evaluation, challenge verification and authorization stay inside your project. External providers are optional, not required.
SELF-HOSTED SECURITY · PRE-1.0
Bot protection with the trust decision kept on your server.
2IZI Guard protects forms and public actions with local risk evaluation, adaptive friction, and single-use server authorization tokens. No mandatory external CAPTCHA runtime.
No mandatory Google, Yandex, Cloudflare, external API, CDN, or third-party telemetry in the core runtime.
PHP 8.1+AdaptiveShadow ModePrivacy-first
2IZI Guardlocal decision surface
actionregister
origin2iziguard.com
sessionbound
modeAdaptive
local risk18/100
PASSsilent
Context
Risk
Challenge
Token
Consume
0required third-party calls
256-bitopaque token
HMACstate integrity
1×atomic consume
0required outbound runtime calls
256-bitopaque token entropy
3×action / session / origin bound
1×atomic one-time consume
Built for application actions
Security is a server decision, not a widget state.
A visible challenge is only one layer. Guard protects the server-side action before the business operation is allowed to run.
Server-side authority
JavaScript success is never authorization. The protected endpoint verifies and consumes the Guard token on the server.
Adaptive friction
Trusted traffic can pass silently. Higher risk can trigger Proof-of-Work, hold-to-confirm, throttling or denial.
Velocity-aware
Rate limits can combine network, Guard session, account, action and site-wide context instead of trusting IP alone.
Privacy-first signals
IP and browser signals are not treated as identity. Guard favors short-lived first-party state and avoids invasive fingerprinting by default.
Explainable decisions
Risk decisions retain reason codes and Shadow Mode predictions for tuning without exposing internal scoring to the requester.
How it works
One protected action. Five independent checkpoints.
The browser can participate in the challenge, but permission to run the business action is always issued and consumed by the server.
01
Validate context
Origin, action, session and coarse limits are checked before expensive work.
02
Score locally
Server and application signals produce an explainable risk decision.
03
Add friction
The policy can choose PASS, Proof-of-Work, interaction, throttle or deny.
04
Issue once
A random 256-bit opaque token is bound to session, action, origin and a short TTL.
05
Consume atomically
The business endpoint consumes the token once; replay, mismatch and expiry are rejected.
Threat model
Assume the attacker knows the entire codebase.
2IZI Guard follows a Kerckhoffs-style assumption: source code, JavaScript, API contract, database schema, PoW algorithm and thresholds may be known. Security must still hold because secrets and authorization remain server-side.
Assume the attacker has
- full source code
- modern AI models
- Playwright / Selenium / headless Chromium
- residential proxies
- captures of their own traffic
Security does not rely on hiding
- JavaScript
- challenge algorithms
- field names
- endpoints
- risk thresholds
Open source
Public code should increase scrutiny, not weaken the model.
Reading the implementation must not create an authorization bypass. Public review is useful when releases, keys, repository permissions and vulnerability handling are disciplined.
Publish
- source and change history
- SECURITY.md and responsible disclosure
- threat model and architecture
- automated security / red-team tests
- release checksums and notes
Keep private
- production config/guard.php
- APP_KEY and HMAC/privacy/rate-limit keys
- database dumps and real security events
- real cookies, tokens and sessions
- deployment secrets and private infrastructure details
Integration
Small integration surface. Final permission stays server-side.
The current core targets PHP 8.1+ and is framework-independent at the security boundary. Protect each action explicitly and consume the token before running the business operation.
Typical actionsloginregisterpassword_resetcontactcheckoutfile_upload
FrontendHTML
<script src="/guard/public/assets/guard.js" defer></script> <form data-guard-action="contact"> … </form>
Protected actionPHP
$result = Guard::verifyAndConsume( $_POST['guard_token'] ?? '', 'contact' ); if (!$result->allowed()) { http_response_code(403); exit; }
PRE-1.0
Current status
0.4.10 · pre-1.0 · active development
The current branch has a security-first architecture and automated regression/red-team coverage. Deploy gradually: Shadow Mode first, then calibrated enforcement on real traffic.
PHP coreAvailable
Webasyst / Shop-Script adapterAfter core stabilization
Verified agents / Privacy PassFuture / standards-dependent
Release0.4.10 · pre-release
FAQ
Clear claims. Clear limits.
Does public source make Guard easier to break?+
It makes the implementation easier to study, which is why the security model cannot depend on obscurity. Bugs can still exist; public review, tests and responsible disclosure help find them earlier.
Does Guard replace MFA, passkeys or a WAF?+
No. Guard is an anti-automation and abuse-protection layer. Critical accounts and transactions still need authentication, authorization, CSRF protection, MFA/passkeys and appropriate infrastructure controls.
Does the core runtime need Internet access?+
No mandatory outbound request is required for the core protection flow. Updates, repositories and future optional attestation providers are separate.
Can an advanced bot still pass the interactive check?+
Yes. Controlled browsers, AI and human solver farms can imitate interaction. That is why the challenge is not the final authorization boundary; server-side context, rate limits, tokens and business policy still apply.
Build abuse protection you can inspect.
Local runtime. Server authorization. Public threat model. No mandatory external CAPTCHA dependency.