Security objective
Authorize every action before execution and return verifiable evidence after execution.
Security by design
Myve executes actions server-side with policy gates, identity binding, and full traceability. This is execution control, not browser automation.
Security control rail
Security objective
Authorize every action before execution and return verifiable evidence after execution.
Control stance
Prompt text never executes directly. Schema validation and policy checks are mandatory gates.
How different integration approaches change risk exposure.
UI scraping
Client agents
API only
Myve
These controls are enforced at execution time, not added as after-the-fact monitoring.
OAuth2, JWT, API keys, and optional mTLS at the execution boundary.
RBAC and ABAC decisioning before action mapping and execution.
Trace IDs, timestamps, actor binding, and decision context for each action.
Minimal retained data by default with explicit retention controls.
Privacy posture is set by architecture: constrained execution paths, no uncontrolled sessions, and minimal default retention.
Built for teams that need defensible controls, clear boundaries, and auditable execution evidence.
Compliance posture
Designed for regulated workflows where auditability and authorization boundaries are mandatory.
Certification status
SOC2 and ISO alignment roadmap is in progress. No unsupported certification claims are made.
Threat model note
Model output does not execute actions directly. Execution requires schema validity, policy allow, and explicit action mapping.
Myve keeps action execution inside your boundary with explicit authorization, deterministic behavior, and verifiable logs.