00 · ABSTRACT # The architecture earns the audit. Certification status is stated plainly: held, in progress, or roadmap. Nothing is badged that is not held. - SOC 2 Type I · ROADMAP - ISO 27001 · mapping in progress - HIPAA · mapping in progress [Review the architecture with us](https://rensei.ai/security#contact) [Read the evidence](https://rensei.ai/evidence) 01 · FRAMEWORKS ## The frameworks a security review asks about. Nine frameworks, each named with its current status and the controls the mapping rests on. The REV date above is the as-of date. Framework Status Mapping scope SOC 2 Type I AICPA Trust Services Criteria ROADMAP Mapping scope Security and confidentiality criteria against Cedar policy scope, access control, and the audit chain. ISO 27001 Information security management systems mapping in progress Mapping scope ISMS control families against Cedar policy scope, access control architecture, and incident response. HIPAA Health Insurance Portability and Accountability Act mapping in progress Mapping scope Technical safeguards: audit controls, access control, and transmission security. GDPR EU General Data Protection Regulation mapping in progress Mapping scope Data handling, retention controls, crypto-shredding, and the DSAR path documented in the privacy policy. PCI DSS Payment Card Industry Data Security Standard mapping in progress Mapping scope Logging, access control, and egress restriction controls. NIST AI RMF NIST AI Risk Management Framework mapping in progress Mapping scope GOVERN, MAP, MEASURE, and MANAGE functions against policy enforcement, decision provenance, and the audit chain. ISO 42001 AI management systems mapping in progress Mapping scope AI management system requirements for risk, transparency, and accountability. EU AI Act EU Artificial Intelligence Act mapping in progress Mapping scope Traceability, technical documentation, and human-oversight requirements for high-risk systems. FedRAMP Federal Risk and Authorization Management Program ROADMAP Mapping scope Sequenced after SOC 2. 02 · CEDAR ## Policy enforcement in the hot path. Every outbound action carries a Cedar evaluation inside the request path. The ruling lands before the action does. Policy is data. A Cedar statement reads as a sentence about a principal, an action, a resource, and the conditions under which the combination is permitted, so a security engineer, an auditor, and a platform engineer reason about the same file without translation. Entity data populates from the systems a team already runs: directories, ticketing, change management. A condition like "the linked change record is approved" is expressed directly in the policy. Policy evaluation runs Rensei's TypeScript implementation of the Cedar policy language, validated against a conformance suite for the Cedar subset in use. It is not the AWS-hosted Cedar service or the Rust reference engine. Forbid clauses win over permit clauses, and one enforcement point covers tool invocations, credential references, agent-to-agent dispatch, memory transfers, and workflow controls alike. The [Cedar policy reference](https://rensei.ai/docs/security/cedar-policies) carries the entity schema and the worked policies. Cedar policy ``` // Permit code push only when the linked ticket is DONE// and the agent is acting on behalf of the authorized principal.permit ( principal == Agent::"rensei-fleet-01", action == Action::"push_to_branch", resource in Repository::"api-service")when { context.ticket.status == "DONE" && context.ticket.assignee == principal.operator_id}; ``` Cedar is open source. Policies are auditable without Rensei tooling. 03 · AUDIT CHAIN ## Tamper-evident by construction. Current append-path Ed25519 signing, a published verification protocol, and a chain any holder can check. Entries produced by the current append path are hash-linked and carry per-workspace Ed25519 signatures. Retained history can include legacy unsigned entries. The [verification protocol and key catalog](https://rensei.ai/.well-known/audit-keys.json) document how workspace-scoped keys are discovered. A [redacted signed sample](https://app.rensei.ai/.well-known/audit-sample) supplies one entry, its key-discovery URL, and an offline verification command. Signature presence and verification are distinct: a holder verifies a supplied entry or segment by recomputing hashes and checking each signature. Successful verification establishes tamper-evidence for the entries supplied and linkage within that retained segment. It does not establish capture or full-history completeness, continuous monitoring coverage, truth at capture, or whether records outside the segment existed. External timestamp anchoring is not part of this published proof. The [audit-trail reference](https://rensei.ai/docs/security/audit-trail) states the same scope for the platform chain, and names anchoring as a separately configured operator action. Crypto-shredding removes payload plaintext while hashes preserve chain integrity. Key rotation is currently a metadata operation; re-signing historical chain segments is on the roadmap. Customer-held keys and HSM support are on the on-prem roadmap. Signing and canonicalization caveats are documented on the [verification method page](https://rensei.ai/verify) , next to the keys. FIG 3.0 *FIG 3.0 - Hash-chained audit events, the chain-verification walk, and one entry expanded into decision provenance.* Figures are live component renders, not screenshots. Demo data. 04 · EGRESS ## Egress fails closed. A missing ruling is a deny. Enforcement is per-callsite: every outbound tool call passes a Cedar policy-enforcement point before egress, and a missing or failed ruling denies by default. There is no separate network-level gateway appliance; the enforcement point lives in the execution path itself. The fail-closed surface is every call that modifies external state: file writes, API calls, repository pushes, notification sends. Observation-only reads proceed under policy-engine outage and still land on the audit chain. Workflow authors declare which steps modify state, and lint tooling flags state-modifying patterns inside steps declared observation-only. 05 · PROVENANCE ## Every decision, reconstructable. A decision record binds the model, the prompt envelope, the retrieved context, and the ruling to one signed audit entry. The same prompt sent to the same model at two different times can return different output. The decision record holds what the moment held: the exact model name and version, the prompt envelope, references to the retrieved context, the Cedar ruling that authorized the action, and the signature binding all of it to one audit entry. An investigation starts from a decision id and walks back to everything that produced the action. Provenance claims one thing: the decision that was made is fully attributable. FIG 5.0 *FIG 5.0 - One decision record reconstructed: model, prompt envelope, retrieved context, Cedar ruling, cryptographic proof.* 06 · DEPLOYMENT ## Where the platform runs. Cloud today. VPC and on-prem ship on the published roadmap, in that order. Dates publish once committed. - CLOUD TODAY Rensei operates the platform. The audit chain, its published verification keys, and the policy enforcement path are the same mechanism across every tier. - VPC ROADMAP The control plane deploys inside the customer's cloud account. First in line on the deployment roadmap. - ON-PREM ROADMAP Customer-owned infrastructure. Customer-held keys and HSM support are scoped to this tier. 07 · THREAT MODEL ## Five named scenarios. The threat model assumes a capable adversary with partial access to the environment. Agents hold elevated privileges, and the design treats them the way privileged access management treats people. 01 ### Prompt injection Instructions injected into retrieved data attempt to steer the agent into unauthorized actions. Policy evaluation sits outside the model: a Cedar policy that denies a push to main is not overridden by a retrieved document that asks for one. 02 ### Policy tampering An actor with partial access edits a policy to widen its own permissions. Policy changes are themselves recorded events: each change passes policy evaluation and lands on the hash chain beside every other action. 03 ### Audit chain manipulation An actor deletes or rewrites audit records to hide an action. Within a supplied contiguous segment, hash chaining exposes an interior removal at the break point, and signature verification exposes a rewritten entry. Verification of that segment does not prove an unanchored tail was not truncated. 04 ### Model substitution A different model version answers than the workflow expected. Decision records capture the exact model name and version at decision time, so substitution surfaces in provenance review. 05 ### Egress bypass A step attempts to reach an external system without a ruling. Agent steps hold no direct network access; the runtime mediates every outbound tool call through the Cedar enforcement point in the execution path, and a missing ruling denies by default. 08 · DISCLOSURE ## Coordinated disclosure. What exists is linked. What does not exist yet says so. Contact [security@rensei.ai](mailto:security@rensei.ai) . A human acknowledges within 48 hours. The machine-readable contact is published at [/.well-known/security.txt](https://rensei.ai/.well-known/security.txt) per RFC 9116. Policy The full disclosure policy covers acknowledgment windows, triage timelines, scope, safe harbor, and credit. [Read the disclosure policy](https://rensei.ai/security/disclosure) . Engagement No independent assessment report is published today. The engagement scope and findings summary publish here on completion. Trust Center Available on request: [security@rensei.ai](mailto:security@rensei.ai) . 09 · CONTACT ## Review the architecture with us. Bring the audit pressure behind your deployment. Every message reaches our team and gets a reply. [Review the architecture with us](https://rensei.ai/security#contact-form) [Read the evidence](https://rensei.ai/evidence) --- Canonical: https://rensei.ai/security Site index: https://rensei.ai/llms.txt Docs: https://rensei.ai/docs OpenAPI: https://rensei.ai/openapi.json