Autonomous AI agent due diligence: what enterprise CISOs and VCs require

The shift from model metrics to execution safety

During the early phases of autonomous agent development, engineering teams and investors focused on benchmark evaluations: reasoning accuracy, coding speed, and multi-step tool call success rates.¹

In 2026, the evaluation criteria have fundamentally matured.

When an autonomous system operates on read-only data, a hallucination results in an incorrect answer. But when an agent receives credentials to mutate PostgreSQL, execute Stripe refunds, or alter hospital clinical records, a hallucination results in physical data loss, regulatory liability, and operational downtime.

Enterprise CISOs, procurement committees, and institutional investors now evaluate AI agent companies on their execution boundary controls. Showing that an agent uses prompt instructions to behave responsibly is no longer sufficient. Production readiness requires deterministic systems engineering that ensures unpermitted actions cannot commit to disk.

The four pillars of agent due diligence

Engineering teams preparing for security reviews or investor diligence must demonstrate four distinct layers of operational defense:

Code What the screen or file shows, copied as is.

┌────────────────────────────────────────────────────────┐
│             Autonomous Agent Execution Loop            │
└───────────────────────────┬────────────────────────────┘
                            │
                            ▼
┌────────────────────────────────────────────────────────┐
│ 1. Pre-Execution admission gate (CEL deterministic)    │
│    Intercept tool call before socket execution         │
└───────────────────────────┬────────────────────────────┘
                            │ Allowed Call
                            ▼
┌────────────────────────────────────────────────────────┐
│ 2. Two-Party Human Approval Perimeter                  │
│    Hold high blast radius actions for human sign-off   │
└───────────────────────────┬────────────────────────────┘
                            │ Approved
                            ▼
┌────────────────────────────────────────────────────────┐
│ 3. Storage Layer Verification (Postgres WAL Diff)      │
│    Read physical write-ahead log tuples committed      │
└───────────────────────────┬────────────────────────────┘
                            │
                            ▼
┌────────────────────────────────────────────────────────┐
│ 4. Cryptographic Provenance Record (Ed25519 Sealed)    │
│    Tamper-evident record chain verified offline        │
└────────────────────────────────────────────────────────┘

Pillar 1: Pre-execution deterministic admission gates

Before any tool call reaches a database driver or third-party API, it must be evaluated by a declarative policy engine.⁴ Prompt-based guardrails fail because language models can be steered by jailbreaks, prompt injection, or subtle context drift. Deterministic Common Expression Language (CEL) policies enforce unbending rules: statements lacking a WHERE clause, or commands targeting protected system tables, are blocked before the database socket receives them.

Pillar 2: Two-party approval routing

Automated workflows must support human intervention for actions exceeding a defined blast radius. If an agent attempts to delete more than 20 rows, drop a table, or refund a transaction above a threshold, the action is suspended until authorized by an engineering lead or clinician.

Two-party approval creates an unskippable perimeter. When an agent requests a sensitive schema alteration or initiates an irreversible financial mutation, Deedglass creates an approval request. The agent cannot self-approve its own operations. Until a designated human operator reviews the proposed diff and provides a counter-signature, the database connection holds the call in a suspended state.

Pillar 3: Physical change log inspection

An agent’s textual report cannot serve as verified evidence of what changed. Deedglass reads the actual tuples committed in PostgreSQL write-ahead logs via logical decoding.² This enables the engine to verify whether the agent’s claim matches reality (Claimed versus Checked levels).

Pillar 4: Cryptographic audit permanence

Every action, policy evaluation, and storage diff must be hashed and signed with private Ed25519 keys into a chained ledger.⁴ These sealed records can be verified offline by auditors without network access or vendor lock-in.

Storage ground truth versus prompt monitoring

A frequent flaw uncovered during enterprise security audits is reliance on prompt firewalls.

Security teams often discover that developers placed a semantic classifier in front of a model, assuming it would catch dangerous SQL or destructive API calls.⁴ When auditors test these systems against real-world relational databases, the abstraction fails:

• Cascading deletions: An agent deletes a single user record, unaware that foreign keys cascade across five audit tables.
• Truncated updates: A query contains an unconstrained SET clause due to parsing errors.
• Race conditions: Two concurrent agent workers read stale state and overwrite each other’s transactions.

A prompt filter cannot detect relational state transitions because it has no awareness of database catalog schemas. Storage-level verification treats database changes as physical events that must be measured from write-ahead logs, rather than conversational outputs that must be filtered for polite wording.

You can inspect the difference between predicted effects and physical database results in real time using the /check/ai change inspector.

Cryptographic audit chains for audit readiness

When institutional auditors evaluate autonomous workflows under SOC 2, ISO 27001, or healthcare regulations, standard application logs are inadequate. Plain text application logs can be modified, truncated, or forged by compromised service accounts.

Deedglass seals each action into a cryptographic record:

Code Data in JSON, the format software uses to pass records and settings.

{
  "action_id": "act_01k8309f",
  "agent_id": "cursor_coding_agent",
  "tool": "postgres.execute",
  "policy_decision": "allow",
  "evidence_level": "Checked",
  "storage_diff": {
    "table": "public.orders",
    "rows_affected": 1,
    "committed_txid": "90412"
  },
  "prev_hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  "signature": "ed25519_sig_8f3a91..."
}

Because each record references the hash of the preceding record, altering or omitting a historical event breaks the cryptographic chain. External auditors can run verification binaries offline against your public key to validate execution provenance without sharing sensitive table data.

Test this verification flow in your browser on the /play interactive sandbox.

Evaluating your agent stack with open-source tools

Before presenting an autonomous agent deployment to an enterprise client or investment partner, engineering leaders should audit their current configuration.

Run the open-source scanner from your project root:

Code Commands typed in a terminal. The text around it says what happens.

npx deedglass scan

The scan inspects your configuration files (.cursor/mcp.json, claude_desktop_config.json, and database roles) across five key vectors:

1. Are database roles granted superuser or bypass row-level security permissions?
2. Are MCP servers wrapped with read-only controls?
3. Are high-risk write paths gated by deterministic policy?
4. Are database connections using logical replication for change observation?
5. Are credentials isolated from prompt contexts?

The tool assigns an overall blast-radius score from A to F. Review the detailed formula and worked deduction examples on /score.

When conducting technical due diligence, venture capital partners and security review boards frequently ask for the raw output of this scan. A grade of A indicates that database credentials cannot bypass row security, that destructive statements are blocked at the perimeter, and that write-ahead logs verify every committed transaction. A grade of D or F exposes immediate remediation requirements before production deployment can be approved.

The path to institutional adoption

The transition from experimental agent prototypes to enterprise infrastructure requires an uncompromising commitment to deterministic safety.

Venture capital investors and enterprise procurement officers are eager to back autonomous agents that deliver genuine business leverage. What they cannot accept is unquantified risk. By anchoring agent tool calls to deterministic CEL gates, verifying commits directly from database change logs, and maintaining cryptographically sealed audit records, startups transform experimental agents into dependable enterprise software.

Written with AI assistance and checked against our claims register.