Security & data handling

Hosted to try. Private to run. For customer security reviews of Check Write™ and TC Protect™. Honest posture: metadata-first, called gate, customer-owned execution, not SOC 2 certified yet.

Product stance (short answers)

• Does TekCapitol execute the write? No. Your application, agent harness, or orchestrator still owns execution after Allow, Pause, or Block.
• What data does TekCapitol receive? Write intent metadata and control evidence you send in the Check Write™ request (see below). Not a crawl of your systems of record by default.
• Where does evaluation happen? Hosted SaaS for build and evaluation, or private runtime (customer VPC / private cloud / on-prem) when production decisions must stay inside your trust boundary.
• What leaves the customer environment? Only what the caller includes in the authenticated request (plus Trace metadata when enabled). Prefer identifiers and stamps over bulk payloads.
• Can Check Write™ run inside the customer trust boundary? Yes. Private runtime deployment is available for regulated production.
• What if the service cannot return a valid decision? SDK paths that require a valid decision fail closed (timeout / invalid response). Skipping the call means the write is not under Protect.
• What evidence is retained? Decision outcomes, reasons, per-control detail, and Trace metadata (tool names, timestamps, policy tags) as configured for the deployment.

What TekCapitol™ sees (Protect Live default)

• Write Intent metadata the orchestrator emits (object ids, intended field changes, authority source, freshness stamps, agent / workflow / run ids).
• Gate decisions: allow / block / pause, reasons, auditId.
• Trace metadata: tool names, timestamps, policy tags, operator pause state.

What TekCapitol™ does not do by default

• Does not query or crawl Salesforce, SAP, Snowflake, or your databases.
• Does not MITM your SoR APIs.
• Does not require raw prompts or full record payloads in SaaS Trace.
• Does not claim SOC 2 (or equivalent) certification today.

Minimization

Send only what policy needs: identifiers, intended changes, independent authority values, freshness signals. Prefer hashes or stamps over bulk field dumps. Contracted exceptions (deeper payloads, VPC retention) are explicit on the order.

Four access models (services / Diagnose)

For assessment and guided work, your security team chooses:

1. Metadata-only: schemas, policies, configs; lowest friction.
2. VDI / customer environment: work inside your estate.
3. Customer laptop / supervised session: paired access.
4. Scoped read-only credentials: least privilege, logged.

NDA and DPA before day one when engagement requires it.

Hosting

Evaluate in SaaS. Decide inside your trust boundary when required. Same decision logic. Different deployment boundary. Regulated teams are not required to run production decisions on hosted SaaS.

• Hosted SaaS: Evaluate and build (developer onboarding, Diagnose, sandbox, policy design). Production decisions can stay hosted when appropriate.
• VPC / private deploy: available for regulated production: customer VPC, private cloud, or on-prem.

Control model honesty

Check Write™ is a called gate. Production paths must invoke check_write / guardedWrite. Skipping the call means the write is not under Protect. v0 does not include cannot-bypass middleware.

JWT and JWKS verification (identity and attestation)

When a sensitive write arrives at check_write, TC Protect™ verifies the signed Write Intent Envelope using the trust material stored in the Agent Registry:

• HS256: validates the JWT signature using signing_secret.
• RS256 and ES256: validates signatures using registered public keys derived from JWKS material (matched by JWT kid when present) or inline public_key_pem / certificate_pem.
• Issuer attestation: if configured, TC Protect compares the JWT iss claim to the registry expected_issuer.
• Payload attestation: TC Protect compares the JWT payload fields to the envelope fields. Any mismatch blocks with SIGNATURE_INVALID.
• Legacy fallback: if signature is not JWT compact, TC Protect verifies legacy HMAC-SHA256 hex signatures.

Agent Registry and Workflow Registry (what is attested)

Identity verification is grounded in two registries, which TC Protect uses during each sensitive check_write evaluation.

• Agent Registry: approved agent trust configuration (approved agent_id and versions, allowed JWT algorithms, and the verification material used to validate signatures), including HS256 signing secret or RS256/ES256 key material (JWKS, inline public key PEM, or certificate PEM). When configured, it also stores expected_issuer for JWT issuer attestation.
• Workflow Registry: approved workflow fingerprinting and runtime constraints, including workflow_id, workflow_version, and a deterministic definition_hash attestation fingerprint. It also stores what the workflow is allowed to do (allowed target systems and operations) and the drift policy used when the definition hash changes.
• Trace visibility: the Trace UI shows these as separate “WRITE CHECKS (metadata)” pills for Agent identity and Workflow identity, alongside Current authority and Write policy.

Check Action (engine under Check Write™)

Deeper in the product: Check Action evaluates whether an agent may perform a specific action right now (scoped authority, intent drift, delegation, blast radius). Marketing stays on the write wedge. Security reviewers can read the engine docs.

Enterprise control evidence

A Check Write™ request can include the controls required for the action and current evidence supplied by the authenticated enterprise caller. TekCapitol evaluates this evidence but does not become the source system for identity, approval, risk, compliance, or business context.

v1 trust model: external control evidence is caller-asserted within the authenticated request. Source-bound or independently attested evidence is an additional enterprise-hardening capability, not a requirement for the current contract. TekCapitol does not independently query every source system.

Related legal

Terms of Service · Privacy Policy · AI Disclosure

Also in Docs

• Write Intent schema · what metadata the orchestrator emits
• Salesforce Check Write™ integration · product brief and high-assurance mode
• SAP Check Write™ integration · product brief and high-assurance mode
• Snowflake Check Write™ integration · product brief and high-assurance mode
• ServiceNow Check Write™ integration · product brief and high-assurance mode
• Check Write™ design v0 · decision API and audit log

Questions for a security review packet: email info@tekcapitol.com. We do not invent certifications or customer logos.