> For the complete documentation index, see [llms.txt](https://hypotheca.gitbook.io/hypotheca-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hypotheca.gitbook.io/hypotheca-docs/hypotheca/technology/security-verification.md).

# Security Verification

How Hypotheca validates security audit reports before allowing an agent to access credit.

Credit access depends on more than who the borrower is. Hypotheca also evaluates what the borrower is running.

An agent must provide a current security audit report. Hypotheca validates the report's content integrity and risk classification before the agent can pass this independent layer of the Credit Gate.

### Security report requirements

The latest audit report must satisfy every required condition:

* A report exists.
* Its timestamp is within the last seven days.
* Its IPFS hash matches the stored content.
* Its risk score satisfies the applicable threshold.
* It contains no critical findings.
* It has not been revoked.

Together, these checks prevent an old, altered, revoked, or materially unsafe report from being treated as current security evidence.

### Risk scoring

The security risk score measures the reported security posture. It is distinct from the 0–1000 Hypotheca Credit Score, which combines multiple signals.

| Risk Score | Status   | Credit Treatment                                |
| ---------- | -------- | ----------------------------------------------- |
| 0–20       | Pass     | Full credit access, all tiers                   |
| 21–50      | Review   | Standard credit access, capped borrow           |
| 51–80      | Caution  | Borrow denied, security report renewal required |
| 81–100     | Critical | Borrow denied and flagged                       |

The whitepaper's verification logic accepts reports with a risk score of **50 or below**. Caution and Critical reports are denied.

### Verification logic

```
Security_Pass =
Report_Exists
AND Report_Fresh
AND IPFS_Hash_Matches
AND Risk_Score <= 50
AND No_Critical_Findings
AND Report_Not_Revoked
```

Every condition is required. A rejection at this layer prevents the agent from progressing through the complete borrowing gate.

### Freshness

Security posture can change. An audit is therefore time-bounded evidence, not permanent proof.

The latest qualifying report must remain within the defined seven-day window. Hypotheca validates submitted or registered audit evidence against this rule. It does not itself continuously audit the agent.

### IPFS integrity

The stored IPFS hash provides a content-integrity check. Hypotheca compares the expected hash against the stored audit content.

If the content does not match, the report cannot be accepted as valid evidence.

### Risk decision flow

```
Audit Report Exists
        →
Check Timestamp
        →
Verify IPFS Hash
        →
Evaluate Risk Score
        →
Check Critical Findings
        →
Check Revocation Status
        →
Pass or Reject
```

This sequence validates whether the report can represent the agent's current security posture for the requested borrow.

### Security verification is a gate, not a guarantee

{% hint style="warning" %}
Passing security verification does not automatically approve borrowing.
{% endhint %}

The agent must still pass:

* ERC-8004 identity verification.
* Payment verification.
* Asset allowlist checks.
* Oracle status checks.
* LTV requirements.

Security evidence is one required input to the final credit decision. It does not guarantee safety or replace the other controls.

### Example

**Qualifying report**

* Risk score: `15`
* Report age: `3 days`
* IPFS hash: Valid
* Critical findings: None
* Revoked: No

**Result:** Security verification passes.

**Caution report**

* Risk score: `65`

**Result:** Borrow is denied and the security report must be renewed.

### Implementation notes

The verification process evaluates the report timestamp, stored IPFS hash, risk score, critical findings, and revocation status. It accepts the report only when each required check passes.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://hypotheca.gitbook.io/hypotheca-docs/hypotheca/technology/security-verification.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.