BY NEURABYTE
DEVELOPERS

Let an agent use your app without giving it the keys.

You list the operations a model is allowed to ask for, and tag each one with how risky it is. Lore’s server sits between the model and your app: it checks every request against that list and your policy, asks a person to approve the risky ones, lets your code do the work, then checks the result and writes a signed receipt. You don’t adopt our UI; you add a small library in whichever language you already use.

SDKS · SIX LANGUAGES, ONE VOCABULARY
TypeScript
@lore-assist/sdk
Python
lore-assist
Go
lore-assist-go
Rust
lore-assist
.NET
Neurabyte.LoreAssist
Java
com.neurabyte:lore-assist
All six SDKs share the same vocabulary for risk tiers, approval modes, and verification results, so a policy written once reads the same everywhere. They handle retries, backoff, and telemetry for you. An approval is tied to the exact request it was granted for. If a retry tries to swap in something different, it’s refused. TypeScript shares its types through @lore/contracts. SDKs are available to early-access customers.
WHAT A GOVERNED STEP LOOKS LIKE · PYTHON
from lore_assist import AssistApprovalRequired, AssistClient, ControlMode, RiskTier, VerificationCode

with AssistClient("https://YOUR_HOST/api/v1/assist", api_key="...") as client:
    session = client.start_session(transport="api", initial_route="/customers")
    plan = client.generate_plan(session.session_id, "Create a customer record for Acme Corp")
    step = plan.steps[1]

    # Approval is an explicit maker/checker handoff by default.
    try:
        receipt = client.run_step(
            session.session_id, plan.plan_id, step.step_id,
            plan_digest=plan.plan_digest,
            idempotency_key=step.idempotency_key,
            control_mode=ControlMode.SUBMIT,
            risk_tier=step.tier or RiskTier.STANDARD,
            execute=lambda authorization: create_customer_in_your_app("Acme Corp"),
            verification=VerificationCode.VERIFIED,
        )
    except AssistApprovalRequired as required:
        send_to_operator(required.handoff)  # the operator approves; the model never can
        raise

    print(receipt.request_id, receipt.approval_used)
Your server decides, not the model
When a step could delete or change something important, the call comes back saying “needs approval.” A person approves it, and that approval works once, for that one operation. If someone tricks the model with a bad prompt, the worst it can do is ask. It can never approve itself.
You get a receipt for everything
When the step finishes, Lore checks what actually changed and records the verdict. The receipt is signed and linked to the one before it, so nobody can quietly edit history later.
ADDING LORE TO AN APP YOU ALREADY HAVE
1. Write down what the model may do
A short JSON file listing the operations a model can request, each marked read-only, standard, or destructive. Lore validates it and records a fingerprint so it can’t drift unnoticed.
2. Connect it to your app
Three small adapters tell Lore how to read your app’s state, where its screens are, and how to trigger its actions. After that a model can operate the same interface your users see, with the same guardrails.
3. Risky operations wait for a person
It’s fine to list a destructive operation like “delete project.” The model can ask for it, but nothing happens until an operator says yes, exactly as on the API path.
{
  "version": "1",
  "operations": [
    { "id": "navigate",       "riskTier": "read_only"   },
    { "id": "updateSettings", "riskTier": "standard"    },
    { "id": "createProject",  "riskTier": "standard"    },
    { "id": "deleteProject",  "riskTier": "destructive" }
  ]
}

$ lore manifest validate operation-manifest.json
# ✓ valid — 4 operation(s)
$ lore manifest publish operation-manifest.json
# canonical, hashed
CHECKING A RECEIPT WITHOUT US
$ curl "$LORE/api/v1/receipts/public-key"
# → { keys: [{ keyId, publicKeyPem, active }] }

$ curl -H "Authorization: Bearer $LORE_TOKEN" "$LORE/api/v1/receipts/<executionId>/export" > receipt.json
$ lore receipts verify receipt.json --public-key lore-receipts.pem
VALID: Ed25519 v2 signature verifies (keyId d6074a62f28213de)
Anyone can check our work
Every completed action and every block of context a model saw is signed. We publish the public key, so your auditor, or anyone, can verify a receipt on their own laptop without trusting our server or asking our permission.
Tampering shows
The verifier rebuilds the receipt from its contents and compares. Change one field and it says TAMPERED. Because each receipt points at the previous one, you also can’t remove or swap one in the middle without breaking the next.
CONNECT

Connect in one command.

lore memory connect sets up the Lore MCP server in your AI client.

MCP TOOLS LIBRARY
Lore MCP tools library
lore memory connect · lore manifest lint · lore manifest scaffold · lore conform · lore receipts verify
DOCS

165 guides across 12 product areas.

Setup, capture clients, memory, context, State Bridge, manifests, SDKs, receipts, analytics, compliance, security and deployment. Docs are available to early-access customers; ask us for access.

Request docs access →
ACCELERATORS

Start from an accelerator.

Working reference apps wired to State Bridge.

ACCELERATOR
CRM onboarding
Create and enrich customer records, with account-changing steps held for approval.
ACCELERATOR
Finance payments
Prepare, approve and release payments, with maker–checker on every release.
ACCELERATOR
Healthcare records
Read and update patient records under minimum-necessary context policy.
ACCELERATOR
Retail returns
Authorize returns and refunds, with post-state verified against the order.

The model can ask. Only your server can say yes.

Request a demo See integrations
Also from Neurabyte: Cupel
Lore's core mechanisms are patent-pending. Product names are trademarks of their respective owners; listing an integration doesn't imply a partnership.
© 2026 NEURABYTE INC.