Public Due-Diligence Report: Secura

Secura presents itself publicly as a “secure execution” API for autonomous agents, currently in private beta (v0.9.1-beta). The positioning is coherent and easy to read: restrict agent permissions, intercept high-risk decisions, maintain fault-tolerant execution and produce immutable audit logs. The public pages set out a clear narrative built on four primitives — permissions, intervention, resilience, audit — and document access through test keys that expire after 72 hours. [S1][S2]

The level of public evidence nevertheless remains insufficient for production adoption in a sensitive context. The legal, security and status pages linked in the footer returned a 404 page at the time of observation; no privacy policy, terms of use, DPA, SLA, status page, SOC 2 attestation or liability documentation was found on the surfaces reviewed. The “live telemetry” metrics displayed in the public render show 0/100, 0.00% and 0.0%, while the meta description tag states a trust score of 97/100 and reliability of 99.93%. [S1][S3][S4][S5][S6]

Public findings

The operational identity observed is Secura, with the page title “Secura — Secure Execution API for Autonomous Agents”. The homepage describes the product as a “structured safety layer for autonomous agents”, in private beta, and displays v0.9.1-beta. The footer copyright reads © 2025. [S1]

The legal identity is not established by the public surfaces reviewed. Footer links labelled Privacy, Terms, Security, Status and GitHub are visible in the public render, but the routes tested for privacy, terms, security and status return a 404 page. No legal entity name, address, country of incorporation, registration number, data controller, DPO, leadership team or support contact was identified on the homepage or in the documentation. [S1][S3][S4][S5][S6]

Diligence assessment

For a vendor selling an execution security layer, the absence of public legal disclosures is a material trust gap. It does not prove that these elements do not exist internally, but it prevents a buyer, investor or partner from quickly verifying who the contracting party is, who operates the service, which jurisdiction governs the commitments, and which liability regime applies to use. [S1][S3][S4][S5][S6]

Points to clarify before integration

• Contracting entity, registered address, governing jurisdiction and operational contact.
• Terms of use, privacy policy, DPA where applicable, list of sub-processors and incident notification procedure.
• Exact status of the private beta: commercial availability, usage restrictions, support levels and termination policy.

Observed surfaces

The main public surface is https://secura.nanocorp.app/, supplemented by https://secura.nanocorp.app/docs. The homepage sets out a declarative product architecture built on four primitives: Scoped Permissions, Intervention Handlers, Fault Tolerance and Audit Trails. It claims integration in a few lines of code, compatibility with LangChain, CrewAI and custom agents, a webhook-first model for audit tooling, and OpenTelemetry-compatible trace exports. [S1]

The public documentation describes the following API routes: POST /api/keys/trial, POST /api/keys/validate, GET /api/free-period-key and POST /api/v1/execute. The examples show the fields userId, email, metadata, apiKey, task and permissions. The passive observation did not submit any POST request and did not request a key; a plain GET on /api/keys/trial returns 405, which is consistent with a documented POST route. [S2][S11]

The public site is served with headers indicating hosting behind Cloudflare/NanoCorp/Vercel, including strict-transport-security, x-vercel-cache, x-matched-path, x-nextjs-prerender on applicable pages and x-proxy: nanocorp-worker. The page also includes a client-side NanoCorp analytics script. These elements describe the web delivery architecture, but do not support any conclusion about the backend architecture of the Secura API. [S1][S2]

Unverified elements

The sample code installs @secura/sdk, but the public npm registry query for @secura/sdk returned 404 Not found at the time of observation. This may be explained by a private, unpublished, renamed or unindexed package; as things stand, public availability of the SDK is not confirmed. [S1][S10]

The production checkout is a public Stripe link (buy.stripe.com) accessible on passive viewing. No purchase, form or payment data was submitted. [S9]

3.1 Customer data and execution data

Secura describes a service positioned at the core of agent execution. The public examples involve, at a minimum, the collection or transit of a user identifier (userId), an email address, metadata, an API key, a natural-language task and a list of permissions. The homepage also refers to immutable audit logs of every action, decision and state transition, with replay capability for debugging and forensic analysis. [S1][S2]

This surface is sensitive: an agent task may contain customer data, business context, confidential instructions or references to internal systems; audit logs may contain detailed records of decisions and actions. Secura's value depends precisely on its ability to observe and control this information. [S1][S2]

Public evidence is insufficient on the following: privacy policy, processing purposes, log retention period, encryption at rest, any application-level encryption, tenant isolation, data location, sub-processors, data subject rights, deletion, export, DPA and incident procedure. The Privacy and Terms routes return 404, which makes even a basic documentary review impossible. [S3][S4]

3.2 Prompts, injection and control of agentic decisions

Secura's proposition partially addresses agentic failure risk by design: declared permissions, allow/deny lists, intervention handlers able to pause/redirect/halt, a risk score in the example (ctx.riskScore > 0.8) and execution bounded by maxSteps. These elements are consistent with a runtime control approach, rather than a static review of prompts alone. [S1]

The public documentation does not, however, describe the specific mechanisms for resisting prompt injection, indirect instructions, tool confusion, dynamic over-permissioning, context contamination, out-of-scope actions or escalation through multi-step chains. Nor does it specify whether rules are evaluated before each tool call, after each model response, on user inputs, on tool outputs, or through a policy engine independent of the model. [S1][S2]

The claim “Agents operate exclusively within declared boundaries — no scope creep” is a strong one. Without documentation of the threat model, known limitations, false positives/false negatives, adversarial testing and failure conditions, it should be read as product positioning, not as evidence of comprehensive security. [S1]

3.3 Credentials, API keys and access separation

Public access relies on free test keys that expire after 72 hours. The documentation specifies one active key per user, a 409 response if a user has already consumed an expired trial, and validation via Authorization: Bearer, x-api-key or x-secura-api-key. After the first day, validation returns an expiring_soon status, a remainingDays value, a paymentSetupRequired flag and an instruction intended to be relayed by the agent to its user. [S2]

• Key format, entropy, storage and hashing are not publicly documented. [S2]
• Mechanisms for rotation, revocation, forced expiry, rate limiting, abuse detection and account lockout are not visible. [S2]
• Permissions appear to be declared by the integrator in the execution call, but the public documentation does not specify how Secura verifies that a requested permission is authorised by the key, the tenant or the contract. [S2]
• Compatibility with GET /api/free-period-key is mentioned but was not tested, to avoid issuing a key or changing any state. [S2]

A validation endpoint that accepts the key in several locations is convenient for integration, but it increases the need for clear documentation on precedence, logging, secret redaction and prevention of exposure in traces. [S2][S3][S5]

3.4 Payments, conversion and commercial liability

The site links production access to a public Stripe checkout. The documentation states that the expiry and warning payloads include an action URL pointing to production payment. [S2][S9]

Using Stripe Checkout potentially reduces Secura's direct exposure to card data, but it does not replace the vendor's commercial and legal obligations: terms of sale, refunds, taxes, invoicing, support, renewal, cancellation, SLA and liability in the event of faulty agent execution. The Terms and Privacy pages return 404, and no detailed pricing page other than the checkout CTA was observed. [S1][S4][S9]

The fact that the agent is explicitly instructed to tell the user that payment must be set up introduces a specific UX/compliance dimension: the payment instruction is delivered through the autonomous agent, not only through a conventional SaaS interface. [S2]

3.5 Operational continuity, reliability and observability

Secura claims fault tolerance through automatic retry, exponential backoff, circuit breakers and graceful degradation. The homepage highlights a stated latency overhead below 2 ms, OpenTelemetry-compatible traces, webhooks and trust/reliability/multi-step success metrics. [S1]

The public evidence is contradictory. The observed render displays Trust Score 0/100, Reliability 0.00% and Multi-Step Success 0.0%. The HTML meta description tag, by contrast, states Trust score 97/100 and 99.93% reliability. Without a functioning status page, incident history, calculation methodology or evidence of monitoring, it is not possible to determine whether the zeros are placeholders, a rendering bug, missing data, or the actual state of the service at the time of observation. [S1][S6]

The Status page linked in the footer returns 404. This is particularly significant for an agentic execution product: if Secura sits in the critical path of an autonomous agent, its unavailability may block the agent, degrade a workflow or trigger unsafe fallback behaviour. [S6]

3.6 Legal, compliance and security liability

The homepage displays SOC 2 / Type II Ready and describes “compliance-ready” exports. The wording is commercially useful, but “ready” is not an attestation. No SOC 2 attestation, auditor letter, coverage period, control criteria, security policy, trust center page or compliance documentation was found. [S1][S5]

The product claims immutable audit trails and forensic replay capability. These claims create high expectations: log integrity, reliable timestamping, tamper protection, access control over traces, chain of custody, evidentiary export, retention and deletion. No public detail allows these properties to be verified. [S1]

Liability is likewise undefined. If an agent executes a harmful action despite Secura, or if Secura blocks a legitimate action and causes a loss, the public surfaces do not state who bears the risk, which exclusions apply, what support is available, or what correction or notification commitments are provided. [S3][S4]

Public traction signals are weak. The page indicates a private beta and a v0.9.1-beta product. No customer logos, detailed use cases, testimonials, adoption metrics, call volumes, tenant counts, revenue, external benchmarks or meaningful SERP presence relating to Secura were identified in the exact-match queries run. [S1][S12]

The performance metrics displayed are difficult to rely on: the stated overhead is <2ms, but no methodology, measurement environment, percentile, volume or benchmark is provided. The live metrics rendering at zero are inconsistent with the more favourable meta description. [S1]

1. Critical-path dependency. Secura positions itself between the agent and its actions. An outage, high latency or incorrect decision may block or alter workflows. Fail-open/fail-closed modes are not documented. [S1][S6]
2. Beta maturity. The v0.9.1-beta status and the absence of legal/status pages suggest that public maturity remains limited. [S1][S3][S4][S6]
3. SDK availability unconfirmed. The @secura/sdk package referenced in the homepage documentation was not found on the public npm registry queried. [S10]
4. Metric ambiguity. The visible zero telemetry values may be interpreted unfavourably if they remain public. [S1]
5. Checkout ahead of contractual framework. The payment journey is accessible while the terms and privacy policy are not. [S4][S9]

Secura sells a security proposition. This category raises the evidentiary bar: visitors expect a higher standard of rigour than from a general-purpose SaaS product. Three elements may create immediate reputational risk: 404 footer links, live metrics at zero and a SOC 2 / Type II Ready claim with no accompanying explanation. [S1][S3][S4][S5][S6]

The risk is not only that a customer declines to buy; it is that an observer reads the claims as premature. In a sector where terms such as “secure”, “immutable”, “compliance-ready” and “no scope creep” carry weight, it is preferable to publish fewer, better-sourced claims than to maintain absolute statements without documentation. [S1][S5]

The principal legal risks stem from the absence of a public framework rather than from any proven issue:

• Personal data and confidentiality: the example collects an email address and metadata, with no accessible privacy policy. [S2][S3]
• Commercial terms: the production checkout is accessible, with no public terms observed. [S4][S9]
• Execution liability: no public clause defines the limits of liability if an agent causes an error despite Secura, or if Secura blocks a necessary operation. [S1][S4]
• Compliance claims: SOC 2 / Type II Ready and “compliance-ready exports” should be qualified so that they are not mistaken for an actual certification or attestation. [S1]
• Evidence and audit logs: immutability and forensic replay may entail retention, access, deletion and protection obligations that are not publicly documented. [S1]

These findings do not constitute legal advice. They identify the points to be verified contractually before integration or investment.

Minimum conditions before production

1. Publish, or provide under NDA, the legal documentation: Terms, Privacy, DPA, sub-processors, jurisdiction, support, SLA, incident response.
2. Publish a security page covering key storage, encryption, tenant isolation, secret redaction, rotation/revocation, rate limits and threat model.
3. Fix the 404 footer links and explain the live metrics, with calculation methodology and history.
4. Clarify the SOC 2 / Type II Ready status: internal readiness, audit in progress, attestation available, or objective only.
5. Confirm SDK availability, its distribution channel, version, changelog and signing/provenance.
6. Document the limits of protections against prompt injection, tool misuse, over-permissioning and multi-step execution.

Acceptable use at this stage

Secura may be monitored, tested only in a non-sensitive environment with synthetic data, and evaluated as a promising component of a future agentic stack. Any real customer data, secrets, irreversible actions, automated payments, regulated operations or production systems should remain out of scope until these points are clarified.

All sources below were consulted on 2026-08-05 between 13:33 and 13:35 UTC. All access was passive: HTTP GET/HEAD, public browser rendering, page reading and exact-match search queries. No login, purchase, form submission, API POST, port scanning, fuzzing, brute-forcing, circumvention or non-public access was carried out.

The review follows eight sections: identity, architecture, security, performance/traction, operational risks, reputational risks, legal risks and recommendation. Security is deliberately central and divided into six dimensions: customer data, prompts/injection, credentials/API keys, payments, operational continuity and legal/liability.

Each material statement is linked to an observed public source. Where a source does not support a conclusion, the report records a “public gap” rather than an allegation. Negative observations regarding missing pages mean only that the pages were unavailable at the time of consultation; they do not prove the absence of internal or contractual documentation.

• No intrusion, active scanning, vulnerability testing, API POST, purchase or non-public access was carried out.
• The report does not verify backend source code, infrastructure, logs, internal policies, SOC 2 controls, customer contracts or past incidents.
• Displayed metrics may be dynamic; they are documented as observed on 2026-08-05.
• SERP results may vary by location, search engine, personalisation and indexing.
• The Stripe checkout was consulted only to confirm public accessibility, without validating the product, final price, invoicing or terms.
• The absence of a public page does not mean the absence of an internal policy; it means the absence of usable public evidence for this report.

Receive the next public due-diligence report.

Join the TrustworthAgent briefing list for new public reports, methodology notes, and independent diligence snapshots on autonomous AI companies.