> ## Documentation Index > Fetch the complete documentation index at: https://docs.checkfu.com/llms.txt > Use this file to discover all available pages before exploring further. # Security posture > Understand which Checkfu controls are enforced, which remain limitations, and how credentials, revocation, and audit compose. Checkfu assumes that an agent workload can be compromised by prompt injection or attacker-controlled input. The harness, model, tools, files, and code inside a workload boundary are therefore not trusted merely because Checkfu started the Session. This page uses the claim classes from the repository security authority: | Claim class | Meaning | | - | - | | **Threat model** | The adversary or failure Checkfu designs against | | **Enforced** | A control implemented at a trusted boundary | | **Limitation** | A known boundary that must constrain how you use the product | | **Unavailable** | No admitted path currently provides the property | | **Target** | Intended behavior that is not a present guarantee | A typed route, provider adapter, deterministic local test, or configured resource is not automatically a supported capability. Stability, availability, prerequisites, and live evidence are separate. Check the [capability status](/getting-started/status) for the exact deployment and Workspace. ## Credential exclusion and its limits The platform's credential-custody design excludes raw provider credentials from: * model context; * harness configuration; * Session events; * sandbox workloads or mount plans; * public API responses; or * Usage and audit projections. A Vault and Credential remain in runtime-backed trusted custody. A Connection exposes an opaque reference and provider metadata, not secret bytes. When an allowed credentialed action reaches the provider boundary, the trusted adapter attaches the credential after the workload's involvement in constructing the canonical request has ended. Complete credential exclusion across provider response bodies, Tool results, errors, logs, and traces still requires qualification for each supported path. Keeping secrets out of public resource fields does not establish that every failure or diagnostic path excludes them. Use the exact deployment and provider qualification reported by [capability status](/getting-started/status). This control limits what a hijacked workload can read. It does not turn every provider effect into a safe effect; permission, policy, egress, Budget, and provider behavior still matter. ## Enforced: permission, policy, approval, and revocation are checked before an effect A credentialed provider action follows one trust path: ```text theme={"theme":{"light":"github-light","dark":"github-dark"}} authenticated identity → Workspace and Principal scope → PermissionAssignment → ActionPolicy → ActionApproval, when required → live Budget, Connection, Credential, and revocation checks → trusted provider edge → effect disposition recorded in Audit ``` A PermissionAssignment decides whether the subject has the permission. ActionPolicy then decides whether the exact action is allowed, denied, or requires approval. An ActionApproval records the authorized human decision and the frozen context that was reviewed. It is not a standing credential and does not override a later revocation. This chain describes Connections and other PermissionAssignment-gated platform actions. An Agent-declared Custom tool has no PermissionAssignment gate in v1; its AgentVersion-frozen declaration and exact Custom-tool ActionPolicy decide the call, with ActionApproval only when that policy requires it. Revocation is local-deny-first. Once a Connection or Credential is revoked, the next trusted check must refuse another provider effect before the credential is attached. Remote provider revocation can still be pending, and an effect already submitted to an external provider can remain indeterminate. Checkfu must not report that uncertain effect as either definitely applied or definitely absent. Audit is the record that joins these controls. It records identity, authorization inputs, policy disposition, approval identity and decision, and the effect disposition that Checkfu observed. Audit does not prove that an external provider's narrative is true. ## Enforced: requested security grade fails closed An Environment can require an execution security grade. Admission compares that requirement with the exact provider and revision that would take custody. When the provider cannot meet the requested grade, admission is refused rather than quietly substituting a weaker grade. This is a qualification gate. It does not establish a qualified boundary for an unqualified provider, and it does not promote a local adapter test into hosted support. ## Limitations: workload networking and isolation Connection egress is enforced at the trusted gateway where Checkfu constructs the provider request. Workload-originated networking is a different boundary. Current limitations include: * ordinary sandbox allowlists are advisory filters unless the exact provider revision has qualified a stronger `security_boundary` grade; * customer-hosted Docker boundaries remain the customer's operational responsibility and are not a Checkfu-managed isolation claim; * build-time network restrictions do not prove runtime network restrictions; * browser or desktop egress can use paths that an HTTP allowlist does not cover; * terminal and preview surfaces must not be treated as trusted or retained unless their exact lane is qualified; and * local model selection does not by itself prove model or data locality. The exact provider path must be qualified. The existence of a provider adapter is not public support for adversarial managed workloads. The same rule applies to credentialed external providers and computer/browser effects: deterministic fixtures prove contract behavior, while public support requires live evidence for the exact path. ## Current support boundaries The source registry separates the resource surface from the provider or runtime that would perform an effect: * **Sessions and Runs** are customer `alpha` and `hosted`, while real managed execution still requires a qualified runtime tuple. Managed runtime availability is separately `preview` and `rollout_fenced`. * **Zero-data-retention managed execution** is customer `preview`, `rollout_fenced`, limited to the `zdr` retention mode, and requires the hosted ZDR Runner prerequisite plus release evidence. * **Connections** and **Installations and collaboration** are customer `alpha` / `hosted` source rows. Those rows cover Checkfu resource and control-plane surfaces; they do not qualify a provider or a credentialed effect. Checkfu does not operate messaging adapters. Customer-built messaging gateways call the ordinary Session API. Credentialed live-provider qualification and provider-held erasure remain open. * The **Computer** resource surface is customer `alpha` / `hosted` and does not require a runtime journey merely to manage its metadata. That does not admit a Computer provider effect or establish provider support. * **Model routing** is customer `alpha` / `hosted` and requires provider credential custody. A route that appears local does not establish inference or data locality; the exact provider/model/locality tuple needs qualification. * The current registry has no customer capability row with `customer_runner` availability. The Runner protocol is a `runner`-audience, `internal`, `hosted` protocol. A customer-operated Runner is therefore not a customer-supported capability merely because it pairs, connects, or passes a deterministic local test; a customer-facing source posture and exact live qualification would have to land. Use the authenticated [capability status](/getting-started/status) for the deployment and Workspace you will actually operate. ## Limitation: retention, export, and erasure are different controls Standard retention can persist Session content and recoverable artifacts under Workspace policy. Zero-data retention omits execution content from durable custody and therefore cannot offer the same recovery, replay, or export behavior. Current evidence does not establish a complete fence across every sink and every in-flight export or release when erasure completes. Landed export, attribution, Bundle, release/deletion, and durable sink-worklist work narrows the boundary, but does not yet establish complete erasure across every historical execution frame and registered sink, including historical presentation records. Treat erasure completion, downstream copies, provider-held data, and concurrent exports according to the explicit limitations in [Retention and zero-data retention](/concepts/retention-and-zdr) and [Export retained records](/guides/export-your-log). ## What remains yours Checkfu cannot make customer application code trustworthy. Keep Checkfu API keys server-side, authenticate your own end users before asserting a Principal, choose the data allowed to enter an adversarial workload, operate customer-hosted infrastructure to your own boundary requirements, and govern copies exported from Checkfu. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.