Security Department for the Pengyi System
We protect what Pengyi builds.
Security, risk, and compliance engineered into every website, API, dataset, agent, MCP server, and future trading system—from first design to production recovery.
Three practices · One mandate
Build fast. Stay trusted.
We do not bolt security on after deployment. PENGYISECURITY defines trust boundaries, permissions, abuse controls, evidence, approval, and recovery before systems gain real users, real data, or real capital.
Frontend Security
Browser controls, UI safety, deployment integrity, supply-chain review, and strict public/private boundaries.
Explore frontend ↗ Trusted systemsBackend Security
Identity, APIs, databases, data integrity, bot defense, resource limits, and privileged action controls.
Explore backend ↗ Control & evidenceRisk & Compliance
Risk classification, security approvals, audit evidence, exception ownership, incident response, and recovery.
Explore governance ↗Current security register
Transparent by design.
These numbers describe the current security framework—not a claim that future systems are already production-secure.
Security lifecycle
Protection is a state machine.
A document is not a control, and a configuration is not proof. Every release moves through implementation, verification, approval, monitoring, and revocation paths.
First protected system
PENGYIDATA.
A static Cloudflare Pages site today; a governed data platform tomorrow. Its risk class rises automatically when forms, accounts, databases, APIs, or trading actions appear.
| System | Current class | Architecture | Priority | Production writes |
|---|---|---|---|---|
| PENGYIDATA | S0 | Static frontend | Headers · IAM · Deployment | None |
| Future accounts/API | S2 planned | Backend + database | AuthZ · Abuse · Audit | Human gate |
| Future trading | S3 planned | Capital-bearing system | Limits · Kill switch · Review | Independent approval |