DEV Community: iamthat

A resume is read as a match check, not as a story

iamthat — Sun, 01 Nov 2026 04:00:12 +0000

The first pass over a resume is not reading. It is a match check: does the top of the page say which role this person is applying for, and does the rest support it?

When the top of the page holds a summary that could belong to anyone, the reader has to work out the intent. That work is where attention ends.

Four fields

Resume Builder asks for the target role, experience as one line per job, skills, and an optional name. It returns a resume and a cover letter built around that role — not a template with placeholder text to delete.

Price is $5 in USDC on Base, no account. Files are processed in memory and not stored.

The honest limit

A generated resume does not make experience appear. It removes the work of arranging what exists, and it keeps the role visible at the top where the first pass happens.

https://ailegal.legal/resume-builder

What $99 a month proves about your AI agent

iamthat — Sat, 31 Oct 2026 06:16:41 +0000

When an AI agent spends money, two artifacts exist. The first is the transaction: a hash on a chain, visible to anyone. The second is the decision to allow it — and when the decision was no, almost nobody keeps the second one.

Ask a team what their agent refused last month and you usually get a dashboard, a screenshot, or a log where every row says allowed. A dashboard is a claim made by the same system that is being questioned. That is why the interesting artifact is not the allow list. It is the refusal, written down in a form someone else can check.

What a refusal record has to contain

The record has to answer four questions without help from the service that produced it: what was asked, which policy decided, who asked, and can this file be changed after the fact.

{
  "v": 1,
  "prev": "<sha256 of the previous record>",
  "ts": "2026-10-29T09:14:02+00:00",
  "decision": "deny",
  "reason": "payee not in allowlist",
  "policy_id": "E03-allowlist",
  "task_id": "task_7f21",
  "artifact_hash": "sha256:9c1e...",
  "actor": "agent:research-1",
  "meta": {"requested_amount": "12.50", "allowed_max": "0.05"},
  "hash": "<sha256 of this body>",
  "signature": "<Ed25519 signature>",
  "public_key": "<base64 key>",
  "algorithm": "ed25519"
}

Three properties do the work. prev chains each record to the one before it, so deleting a row breaks every row after it. The signature covers the body including prev, so a record cannot be rewritten and re-signed without the key. The public key is embedded, so verification needs no network call and no account with the vendor.

Writing one is a single request:

curl -X POST https://attest.rta.lat/deny \
  -H 'content-type: application/json' \
  -d '{"reason":"payee not in allowlist","policy_id":"E03-allowlist",
       "task_id":"task_7f21","artifact_hash":"sha256:9c1e","actor":"agent:research-1"}'

Reading them back is the other one: GET /deny?since=...&limit=100. Offline check is a function call against the exported log, not a login:

from attest.deny import read, verify_log
verify_log(read())

What it proves, and what it does not

This table is the reason the product exists, and it is more useful than any feature list:

Proves	Does not prove
The record was not changed after issue	That no other chain was shown to someone else
The chain has no gaps (each `prev` matches)	That every refusal in your system reached this log
The signature verifies offline with the embedded key	That the policy behind the refusal was correct

Read the right column twice. A signed refusal log is evidence that a specific decision happened and was recorded in a way that cannot be quietly edited. It is not a certificate of good judgement, and it is not a control: it records what was stopped, it does not stop anything. If you need enforcement before the action, that is a separate layer — a mandate checked against the proposed action, not a log written after it.

Anyone who sells you "compliance" as a single artifact is selling you the left column and hoping you do not read the right one.

Why it costs money at all

Recording a refusal is cryptography, not inference. There is no model in the path: Ed25519 signing and a SHA-256 chain cost nothing per record, which is why the price is flat rather than metered.

The paid plan is $99 for 30 days, unlimited records, one-time payment, no auto-renewal. A trial key starts at 0.01 USDC and covers 100 records over 7 days; free evaluation is 20 records a day. Payment is USDC on Base to the address on the page, and the page issues the API key after the transfer.

Now the honest part about the subscription: the price is not the proof. Paying monthly proves you had $99 and a reason. What proves something is the artifact, and the artifact does not expire with the subscription. Records you already hold keep verifying offline after the plan ends, because verification uses the public key inside the record, not a call to the vendor. If a service's evidence stops working when you stop paying, it was never evidence — it was a rented dashboard.

So what does $99 a month actually prove? That you decided the question "what did the agent refuse, and can I show it later" is worth a fixed line item rather than a screenshot. The rest is arithmetic: signing a record is Ed25519, not inference, so the five-hundredth refusal in a month costs the same as the first — zero.

Where it fits in a real conversation

An auditor asks for a refusal and gets a signed chain with the policy and the numbers. An incident review needs a timeline; the gap is usually exactly where the agent was stopped, and this is the file that fills it. A customer asks what your agent is not allowed to do; the answer is a set of policy ids with the records that applied them.

None of those conversations are won by a dashboard. They are won by a file the other side can check without trusting you.

The contract, the offline verifier and the pricing block are here: https://attest.rta.lat/deny-evidence

A contract scanner that refuses to guess

iamthat — Sat, 31 Oct 2026 06:16:35 +0000

Every AI contract tool I have tried answers with confidence. Ask about a clause that is not in the document, and you get a plausible paragraph with an article number that does not exist. The failure is not that the answer is wrong. The failure is that the wrong answer looks exactly like the right one.

Contract Scan is a small tool that does the opposite, and I want to describe precisely where it stops instead of what it promises. It takes a text PDF or a plain text file and returns two risk flags for free, then five flags with the exact wording to fix for $5 in USDC. That is the whole product. The interesting part is the refusals.

What happens when it cannot read

The file is the first thing that can be wrong, so the tool answers about the file before answering about the contract:

An image-only scan returns 422 with "the file looks like a scan, no extractable text". It does not run OCR and it does not guess at clauses it cannot see.
An empty file returns no text found. A whitespace-only file returns 422 as well.
A file over 8 MB returns 413 with the limit, not a 500 after two minutes of silence.
A PDF that is not a PDF returns the exception class in the message, so you know whether the problem is encryption, a broken stream or the wrong file entirely.

None of this is impressive engineering. It is just the difference between "I could not analyse this" and a confident paragraph about a contract the service never read.

The free pass is rules, not a model

The five risk types are fixed: auto-renewal, unlimited liability, penalties and forfeitures, unilateral change, and a distant forum or arbitration. The preview runs deterministic patterns over the extracted text. The same document produces the same flags on every call, in milliseconds: ten contracts take about 4 ms on the server.

Determinism matters for a boring reason. If a scanner is a model wrapped in a prompt, two runs on the same contract can disagree, and then the output is not a document you can attach to an email to the other side. It is a conversation you had with a service.

The paid report adds a model pass on top of the rules, because live contracts are written in wording no regex anticipates: "liable for all damages", "courts of Delaware", "indemnify". Every flag in the report carries source: rules or source: model, so you can see which mechanism produced it. A flag with no provenance is an opinion with a timestamp.

We published the accuracy, including the failure

This is the part that most tools skip. The rules were measured on ten contracts written as real documents, for a named reader: a tenant in Moscow, a client in New York, an employee in St Petersburg. Each contract had risks planted deliberately, and each flag was checked against the quoted wording rather than eyeballed.

The first measurement, before any of this was announced:

Metric	Measured	Target	Verdict
Completeness (planted risks found)	25 / 34 = 73.5 %	≥ 80 %	not met
False flags	4 / 29 = 13.8 %	≤ 10 %	not met
Flags pointing at a real risk	25 / 29 = 86.2 %	—	—
Server errors on edge inputs	0	0	met

Both thresholds were missed, and the misses were not random. Russian contracts scored 11 of 18 (61 %) against 14 of 16 (88 %) for English ones, because the English rules were written from live contracts and the Russian ones from a dictionary of legal phrases. Nine of nine misses traced back to three holes: Russian morphology, English synonyms for a penalty, and the concept of a "home court", which is not a risk at all when you are the local party.

The same exercise found two ways the scanner could answer "clean" on a dangerous contract: a cp1251-encoded text file silently lost all Cyrillic, and a PDF longer than 40 pages was cut off at page 40. A silent clean is the worst output a scanner can produce, worse than an error.

Both are fixed, with tests, in the same day's commits. The rules now return 35 of 35 planted risks with 0 false flags on that corpus — and that sentence needs a caveat the size of the corpus: the fixes were written against these ten documents, so the second number is a regression baseline, not an accuracy promise. It says the holes are closed. It does not say the next hundred contracts will score the same, and it is pinned in the test suite precisely so that it cannot quietly drift.

If you count risks outside the declared five-type checklist — a five-year non-compete, "as is" with no warranty, termination without a cure period — the ceiling was 61 % on the original run. That is the honest limit of a five-template triage, and it should never be confused with a legal review.

What happens to the file

Files are processed in memory and discarded when the request ends. Only aggregate counters survive: how many operations ran, not the documents. There is no account, so there is no account to leak. Payment is 5 USDC on Base to the address shown on the page; you paste the transaction hash and the page says so when the hash is wrong instead of pretending it worked.

What it is not

It is a reading aid with quoted wording. It is not legal advice, it does not know which side of the contract you are on, and it does not promise an outcome. When the document cannot be read, it says so; when the rules miss, the published number says so for it.

Two free flags, five in the report, and the accuracy table above are all on the page:

https://ailegal.legal/contract-scan

Your agent's log has 1,509 rows and zero denials. That is the problem.

iamthat — Sat, 31 Oct 2026 05:37:56 +0000

An agent that never refuses anything is not a working agent. It is a script with a credit card.

I keep seeing the same artefact offered as proof of control: a log where every row says allowed. Fifteen hundred rows, zero denials, exported to CSV for the auditor. It proves traffic. It does not prove that anything was ever stopped.

What a refusal actually looks like

A deny record is small and boring on purpose:

{
  "v": 1,
  "prev": "<sha256 of the previous record>",
  "ts": "2026-10-31T09:14:02+00:00",
  "decision": "deny",
  "policy": "spend_limit_per_call",
  "requested": {"amount_usdc": 40},
  "limit": {"amount_usdc": 5},
  "subject": "agent:invoice-runner",
  "signature": "ed25519:..."
}

Four properties make it evidence rather than a note:

It exists only when something was refused. If the file is empty, either nothing was stopped or nothing was checked. Both are answers.
It chains. prev binds each record to the one before it; deleting a row breaks every row after it.
It is signed offline. A verifier checks the chain and the signature without trusting the service that produced it.
It names the policy and the numbers. "Denied" is an opinion; "asked 40, limit 5, policy spend_limit_per_call" is a fact.

The question that breaks most demos

Show me one refusal from last week, with the policy that fired.

Most systems cannot answer it, because denials are logged at the same level as successes and thrown away first.

What this is not

It is not a compliance certificate, and it does not make an agent safe. It makes one narrow claim verifiable: this action was stopped, at this time, under this policy, and the record has not been edited since. Everything else still needs a human.

If you already keep such a log, the only thing I would ask: can someone verify it without your dashboard? If yes, you are ahead of most teams shipping agents today.

I build attest, a deterministic verifier for agent artefacts — schema, emptiness, provenance, and mandate authority, one Ed25519-signed verdict. The deny log is public: https://attest.rta.lat/deny-evidence

Two clauses carry most of the risk in a contract you are about to sign

iamthat — Sat, 31 Oct 2026 00:56:42 +0000

A contract is signed at the point of least attention: the PDF is open on a phone, and the only question is where to click.

The expensive parts are rarely in bold. An early-exit penalty, a clause that lets the other side change terms later, a deadline that moves — these decide the cost of the deal, and they sit in the same font as everything else.

What the check does

Contract Scan takes a text PDF or a plain text file and returns two risk flags free, in seconds, without an account. The full report lists five fixes and includes a letter to the other side — $5 in USDC on Base, no card.

What happens to the file

Files are processed in memory and discarded when the request ends. Only aggregate counters are kept — how many operations ran, not the documents themselves. There is no account, so there is no account to leak.

What it is not

The output is a reading aid with cited wording, not legal advice, and it does not promise an outcome.

https://ailegal.legal/contract-scan

Three products, one question: what was the agent allowed to do?

iamthat — Thu, 29 Oct 2026 17:13:37 +0000

The portfolio looks like three products. Operationally it is one question asked at three moments.

1. Before exposure: MCP Security Pass — $500

A server is about to be published. The question is: what can an agent do with it, and what happens when it tries something outside the intended scope?

The pass is a 10-check review: auth, authorization, least privilege, tool descriptions, input validation, secrets, denial logging, replay, transport, supply chain. Output: findings, severity, evidence, fix order.

2. During operation: Deny Evidence — $29/month

The server is live. The question changes: what did the agent try, and what was refused?

A log of allowed rows cannot answer that. A signed refusal record can: policy, reason, task, artifact hash, timestamp. Verifiable offline, without custody.

3. For the buyer: EU AI Act Evidence Pack — $1,500

The product is being sold into the EU. The question becomes: where is the evidence package?

The pack maps the system to record-keeping, human oversight and technical documentation, and includes the deny log as evidence. Five days; express 72 hours for $3,000. Evidence, not a legal opinion or a certification.

Why they are separate

A security review does not need a monthly subscription. A refusal log does not need a consulting engagement. An EU pack does not need a custom audit of every server. Sell the smallest artifact that answers the buyer's actual question.

The shared principle: do not claim safety; produce a record that can be checked.

The portfolio

Deny Evidence — signed refusal log, $29/month: https://attest.rta.lat/deny-evidence
MCP Security Pass — $500 review before you expose a server: https://rta.lat/audit/
EU AI Act Evidence Pack — $1,500 / 5 days; $3,000 / 72 hours: https://attest.rta.lat/eu-ai-act-evidence

What a $29 refusal log actually contains (and what it cannot prove)

iamthat — Thu, 29 Oct 2026 17:13:36 +0000

A refusal log is not a folder of error messages. It is a small evidence format with a specific job: let a third party verify that an enforcement point made a decision, on a specific input, at a specific time.

Here is the shape we use.

{
  "decision": "deny",
  "policy": "payee_not_allowlisted",
  "reason": "recipient is not in the task mandate",
  "task_id": "tsk_01J...",
  "actor": "agent:research-7",
  "artifact_sha256": "…",
  "created_at": "2026-10-29T12:00:00Z",
  "signature": "ed25519:…"
}

What it makes possible

Read-only enforcement — a database tool can show that a write was attempted and refused.
Spend control — a payment rail can show that a payee or amount was outside the mandate.
Buyer review — a security team can verify the record offline without calling your API.
Incident review — "what did the agent try?" becomes a query, not a meeting.

What it cannot prove

It cannot prove the model's intent. It cannot prove that no other path bypassed the gateway. It cannot turn a missing log into a complete one. Those limits belong in the document, not in a footnote.

Verification, not trust

The record is signed with Ed25519 and canonicalized before signing. A verifier only needs the public key and the JSON. If the JSON changes, verification fails. That is the whole trick: make the evidence portable, not platform-bound.

At $29/month, the product is intentionally small. It is a refusal record, not a SIEM. The point is to make the missing question visible before a buyer asks it.

The portfolio

Deny Evidence — signed refusal log, $29/month: https://attest.rta.lat/deny-evidence
MCP Security Pass — $500 review before you expose a server: https://rta.lat/audit/
EU AI Act Evidence Pack — $1,500 / 5 days; $3,000 / 72 hours: https://attest.rta.lat/eu-ai-act-evidence

The EU AI Act deadline passed. The missing artifact is a refusal log.

iamthat — Thu, 29 Oct 2026 17:13:25 +0000

The EU AI Act's high-risk and transparency obligations have been applying since 2 August 2026. If you sell an AI system into the EU, the buyer conversation has changed from "is it accurate?" to "show me the evidence".

What is actually being asked for

For a high-risk system, the evidence maps to:

record-keeping — logs that show the system's operation over its lifetime;
human oversight — who can intervene, how, and what the record looks like;
technical documentation — the model/system description, intended purpose, limitations, and risk controls.

For transparency-scope products the set is narrower. The classification drives the scope; a blanket "we are AI Act compliant" claim is not evidence.

The artifact most teams forget

A log of successful calls is not enough. The reviewer wants to know what was refused and why: which policy fired, which payee was blocked, which task budget was exhausted. That is the deny log.

A useful pack contains:

system description and intended purpose;
model card with known limitations;
audit-log schema and a sample;
human-oversight procedure;
risk-classification memo;
deny/refusal evidence with a verifiable record;
data-flow and subprocessor map.

What we deliver

The EU AI Act Evidence Pack in 5 days for $1,500; express 72 hours for $3,000. It is an evidence package, not a legal opinion and not a certification. The output is designed for a security/legal reviewer to inspect, not for a marketing page.

If your team is still debating whether the product is in scope, start with the classification memo. That is usually the cheapest decision to get right.

The portfolio

Deny Evidence — signed refusal log, $29/month: https://attest.rta.lat/deny-evidence
MCP Security Pass — $500 review before you expose a server: https://rta.lat/audit/
EU AI Act Evidence Pack — $1,500 / 5 days; $3,000 / 72 hours: https://attest.rta.lat/eu-ai-act-evidence

Most MCP servers ship without a security pass. Here is the 10-check one.

iamthat — Thu, 29 Oct 2026 17:12:49 +0000

An MCP server is not a plugin. It is an RPC endpoint that hands an LLM real capabilities: files, databases, internal APIs, payment rails. The security review should look more like an API review than a prompt review.

Here is the 10-check pass we use before exposing a server.

The 10 checks

Authentication — is there any? "It is only localhost" is not a boundary on a shared machine.
Authorization — can a tool be called by a session that should only read?
Least privilege — does the server expose DROP, DELETE, or transfer tools when the use case only needs SELECT?
Tool descriptions — can a description carry instructions that change the model's behavior?
Input validation — URLs, file paths, SQL, shell arguments; SSRF and path traversal are still the classics.
Secrets — are credentials in prompts, logs, or tool results?
Audit and denial — can you show what was attempted and refused, not only what succeeded?
Rate limits and replay — can a retry loop spend the budget or repeat a side effect?
Transport and session — is the endpoint authenticated, scoped, and safe across reconnects?
Supply chain — pinned dependencies, signed images, no unreviewed post-install scripts.

What the pass delivers

A written finding list with severity, evidence (request/response or code path), and a fix order. Not a certification. Not a legal opinion. A $500 review that a maintainer can act on before publishing.

The most common finding is not a sophisticated exploit. It is a write-capable tool exposed to an agent that only needed to read.

The uncomfortable question

If a user asked your server authors today, "show me that this is secure", what would they send? A README? A screenshot? A promise?

A pass gives them a document with a date, a scope, and a list of what was not checked. That is more useful than a badge.

The portfolio

Deny Evidence — signed refusal log, $29/month: https://attest.rta.lat/deny-evidence
MCP Security Pass — $500 review before you expose a server: https://rta.lat/audit/
EU AI Act Evidence Pack — $1,500 / 5 days; $3,000 / 72 hours: https://attest.rta.lat/eu-ai-act-evidence

Your audit log has 1,509 "allowed" rows. That is not evidence.

iamthat — Thu, 29 Oct 2026 15:06:28 +0000

A public post in r/mcp made the gap concrete: an operator counted 1,509 audit rows since August, and every single row said allowed. Zero refusals.

That is not a success metric. It is a missing control.

What an audit log usually answers

Most logs answer what ran. Security teams and buyers ask a different question:

What did the agent try to do, and what was it told no?

If the answer is always "nothing was refused", one of two things is true: the policy is perfect, or there is no policy in the path. The first is rare. The second is common.

A refusal is a data model, not a log line

A useful denial record needs more than status: denied:

actor — browser session or agent key;
task — the envelope, budget, payee allowlist, expiry;
policy — which rule fired and why;
artifact hash — the exact input the decision was made on;
decision and reason — deny, require_approval, or allow;
signature — so a third party can verify the record offline;
timestamp — append-only, not editable after the fact.

That is what Deny Evidence produces. The price is deliberately boring: $29/month. No custody. No token. No dashboard that asks you to trust a green checkmark.

What it does not prove

A signed refusal record proves what the gateway saw and decided. It does not prove the model's intent, and it does not replace a SIEM. If a tool bypasses the gateway, the record is incomplete. The honest claim is narrow: this is the evidence the enforcement point produced.

Why now

Agent payments are moving from demos to procurement. A buyer will ask for traces, approvals, and refusals. A log that only contains "allowed" is a liability disguised as observability.

If you run an MCP server, start by asking what a denied call looks like in your current logs. If the answer is "we don't have one", that is the first finding.

The portfolio

Deny Evidence — signed refusal log, $29/month: https://attest.rta.lat/deny-evidence
MCP Security Pass — $500 review before you expose a server: https://rta.lat/audit/
EU AI Act Evidence Pack — $1,500 / 5 days; $3,000 / 72 hours: https://attest.rta.lat/eu-ai-act-evidence

A legal oracle for agents: three endpoints and one honest refusal

iamthat — Wed, 28 Oct 2026 18:24:35 +0000

An agent can pay for an API in milliseconds. It still cannot answer a simpler question: does this provision actually exist?

That is the gap a legal oracle fills. Not a chatbot that summarises law, but a machine-readable source an agent can query before it signs, files or quotes something.

Three questions, three endpoints

GET /api/v2/oracle/lookup?q=unpaid salary india&jurisdiction=in
→ 4 provisions, each with the official source URL

GET /api/v2/oracle/citation?code=Code on Wages&article=s. 17&jurisdiction=in
→ {"found": true, "verified": true}

GET /api/v2/oracle/citation?code=Fake Act&article=s. 999
→ {"found": false}

The last answer is the important one. A legal AI that cannot say "no verified provision" will invent a plausible section number, and the reader will stop looking for the right one.

Coverage is the product

92 provisions across Russia, India, the US, the UK, Canada and Hong Kong — each read in the official source and re-checked on a schedule. When the corpus has nothing, found: false is returned and the agent must not cite anything.

How agents reach it

MCP, no account, no key:

{"mcpServers": {"ailegal": {"url": "https://ailegal.legal/api/mcp/", "transport": "streamable-http"}}}

Tools: legal_breakdown, oracle_lookup, verify_citation. Free tier 120 calls/hour; volume can go through an x402 per-call rail at $0.05 USDC on Base.

Source: https://github.com/mrpkk/ailegal-mcp (MIT).
Docs: https://ailegal.legal/oracle

If your agent moves money or files documents, the oracle is the part that keeps it honest — and its refusals are as valuable as its answers.

KARTA: The Kill-Switch Layer for AI Agent Spending

iamthat — Wed, 28 Oct 2026 05:02:15 +0000

KARTA: The Kill-Switch Layer for AI Agent Spending

AI agents with wallets are becoming reality. But without control, they can spend too much, too quickly, or to unintended destinations. KARTA provides a simple layer: mandated spending, budget limits, kill-switch, and signed receipts. Every spend is verified before signing.

https://karta.rta.lat

AI #Agents #Web3 #Security #Payments

Agent bill growing faster than usage? We run a 5-day audit on one month of agent logs — duplicate calls, failed-but-billed requests, quote-vs-settled differences, missing refunds. One report, fix order included, $500 in USDC: https://ailegal.legal/audit