DEV Community: turva.dev

I rebuilt turva.dev around the report

Erik Rekola — Mon, 07 Sep 2026 08:09:58 +0000

I have rewritten turva.dev and rebuilt the pages around the work a buyer receives. The home page now leads into two services and their sample reports. Each report shows how an observation becomes a finding, a correction and a check that the correction worked.

That is the part I want someone to be able to inspect before buying an audit.

What changed on the site

The home page separates the focused Shopify storefront check from the broader website and API audit. Each has its own scope and a public example of the deliverable. The process is written out too: agree the question and scope, receive the findings, then make and verify the corrections.

The pages share a common layout. Headings, navigation and report sections follow the same structure across the site. The reports put the summary or decision before the contents and engagement details. Someone opening a long report can see the recommended action first, then follow the evidence behind it.

The guides are grouped by what a reader is trying to do:

Audit, visibility and priorities.
Content and crawl access.
Discovery and authentication.
Commerce and agent operations.

Their source-check dates are separate from the layout update. A redesigned page does not, by itself, establish that its technical advice is current.

This rewrite changed the pages, not the service scopes or the prices.

What the report template has to carry

The useful unit in the template is a finding with enough information for someone else to act on it:

What was checked, under which conditions, and what came back.
Why the result matters to the business question agreed at the start.
Which correction comes first and who owns the work.
What must be available before that work can begin.
How to check the result afterwards, including anything still unresolved.

The website and API report keeps scanner readings, manual observations and answers from AI assistants identifiable as separate sources of evidence. They answer different questions. A reachable interface can return incorrect data. An assistant can repeat an old address even when the current page is accessible.

The report also names the boundary of a correction. Changing a response at the edge can correct what a client receives while leaving the underlying source unchanged. The person responsible for the source needs to know that, and the acceptance check needs to cover the surfaces that matter.

The finding that changes no scanner points

The sample website and API audit uses an invented fastener wholesaler. Every company detail, reading and date in it is fictional.

In that example, the visible product pages show real prices, while the structured data says the products cost zero and are in stock. The API provides another inconsistent representation. Correcting those facts comes before the fixes that improve the scanner result.

That ordering is deliberate. The company's question concerns what a buyer's assistant will read about its products. The report has to follow that question through the evidence and the correction plan, even where the scanner awards no points for the fix.

The sample shows the format and reasoning. It provides no evidence of a result achieved for a real client.

A smaller report for a Shopify question

The Shopify sample report uses a second invented business. It compares selected product variants across the storefront and the agent-shopping surfaces available in the example.

One fictional product has different prices in the storefront and the remote catalog. Another has conflicting availability. The report records the market, variant and session conditions, then gives each mismatch a correction and a retest condition.

It also records where the buyer journey stops. Reaching a checkout handoff does not establish that payment or order creation succeeded. The sample describes no paid order.

This is a narrower deliverable than the website and API audit. Its structure follows the merchant's immediate question: whether the tested interfaces agree about the products, and what the supported journey actually permits.

What I can claim about the update

The site now makes the report structure, service boundaries and next steps explicit. The two samples let a reader inspect the evidence format and correction instructions before contacting me.

I have not measured whether the redesign improves sales or AI citations. Those would need their own observations. Both sample reports remain synthetic, and neither is a certification of a real business.

For someone considering the work, the most useful place to start is the sample for their situation. It shows what I mean by an audit more precisely than a list of protocol names can.

Frequently asked

What should an agent-readiness audit report include beyond a scanner score?

The agreed scope, dated evidence, manual findings, priorities, correction owners and acceptance checks. If AI answers are included, the questions and measurement conditions should be documented separately from the technical scan.

Are the public sample reports real client work?

No. Both use invented businesses and observations to demonstrate the deliverable. They do not show measured client outcomes.

Can a team use the report without buying implementation?

Yes. The correction instructions and acceptance checks are part of the report. Implementation is a separate purchase, with access requirements and responsibilities agreed for that work.

Originally published at https://turva.dev/blog/i-rebuilt-turva-dev-around-the-report

What 19 identity vendors publish for agents

Erik Rekola — Sat, 05 Sep 2026 09:16:44 +0000

I measured 19 companies that build digital identity and trust products, wallets and verifiable credential infrastructure, the parts of the stack meant to let one machine prove something to another machine. Then I asked the simplest question I could think of about them. Can an agent find out anything at all about these companies without a human in the loop.

How this was measured

The measurement ran on 2026-09-05. One full scan per company with the isitagentready.com scanner on its default profile, run one target at a time, plus my own reads with curl against the same hosts. Sixteen checks applied that day. I am not naming the companies, and I come back to why below.

Levels first. Fifteen came out at Level 1, three at Level 0 and one at Level 2. Nothing above that. The average was 2,8 checks passed out of 16.

The column where every one of them scored zero

The scanner has a group for API, auth, MCP and A2A discovery, nine checks in all: apiCatalog, oauthDiscovery, oauthProtectedResource, authMd, mcpServerCard, a2aAgentCard, agentSkills, webMcp and ard. Every company scored zero of nine. Not one of the 19 publishes an API catalog, an OAuth discovery document, an MCP server card, an A2A agent card or an ARD manifest. One authMd check failed with a 500 rather than a 404, which is a broken answer and not evidence of a missing file, and that is the only nuance in the whole column. These are companies whose product is machine to machine verifiable identity.

The smaller readings

Two of the 19 serve no robots.txt at all. A third serves one with no wildcard rule, so the file exists and says nothing about most crawlers. Content Signals, the line where a site declares whether it wants its text used for AI training, appeared exactly once in the set. That company says ai-train=no and search=yes. Markdown content negotiation worked on one company as well, though that is a single reading and I have not repeated it. The same check moved on me within one day on a different site, from 406 to 200 to 200, so I treat it as provisional.

Seven of the 19 have an llms.txt an agent can fetch, and one of those seven is a redirect to a file parked on a marketing platform host. Twelve have nothing there. One of the seven announces in its own first line that a SEO plugin generated it, which makes it the publishing system talking rather than a decision anyone made. Seven of the 19 serve no JSON-LD at all on the front page.

One site where 200 means nothing

One company was different in a way worth describing. I asked for eight paths on that domain and all eight returned HTTP 200 with the same 3021 byte body and an identical sha256. The front page, a real subpage, a path I invented on the spot, llms.txt and four well-known addresses. So the agent addresses answer 200 with a page that is not what was asked for. I opened the site in a browser and the content renders fine, it just arrives after JavaScript has run. An agent that does not execute scripts cannot tell an existing page from one that does not exist. The other 18 answered 404 to the same addresses, which is the correct answer.

What this does not say

I read front pages and root paths and nothing else, so none of it is a statement about anyone's documentation, product API or MCP endpoint. Three of the passing Link header readings come from WordPress serving its own rel=alternate, which is the platform and not the company. Each company was scanned once, and a level from a single run is a snapshot. I tested no products. A site can be hard for an agent to read while the software behind it is excellent, and in this set I would expect that to be the common case.

Why the companies are not named

The finding is not that one company forgot a file. All 19 landed on zero in the same column, which makes this a property of the category rather than of anyone's diligence. I have also not contacted any of them, and a list of names published before that would be a different kind of document than the one I wanted to write. I should be straight about the limit of this though. Every reading above comes from a public surface, so a reader who guesses the set and runs the same scan will work out who is who. Withholding the names is not protection, it is a statement about what the piece is for.

One last thing, and it cuts against me

These checks come from one scanner and the rules move every month. The set of applicable checks grows as new ones are added, so a count from an older run is not comparable with today's. My own site reads Level 5 on that same scanner today, with all 16 applicable checks passing, and that is a snapshot from one instrument on one day, exactly like every number above.

Frequently asked

Does a Level 1 reading mean the company builds bad software?

No, and nothing here measures the software. The scan reads what a website publishes for an automated visitor. A company can run excellent credential infrastructure behind a site that tells an agent nothing about it, and in this set that is the likely case for most of them.

Why would an identity vendor need an MCP server card or an agent card?

Because the thing being sold is machine to machine trust, and a machine that arrives at the site has no way to find the interfaces without one. The gap is not that the file is mandatory. The gap is that these nine addresses are where an agent looks first, and in this set they were empty every time.

Can I get the reading for my own site?

If you are in this set and want your own reading, email me and I will send you the scanner output for your own domain. That is the whole promise, one scan and the raw result, and it is not the paid work.

Originally published at https://turva.dev/blog/agent-readiness-identity-vendors

Two files called auth.md, and they disagree on the field names

Erik Rekola — Fri, 04 Sep 2026 13:44:08 +0000

WorkOS shipped Agent Auth for AuthKit on 2 September, a way to give the agents you build into your own product short-lived scoped tokens instead of a long-lived API key. Next to it in the same product menu sits something else with a wider blast radius, and it is a month older: an open protocol called auth.md, shipped into AuthKit on 4 August, in which a service publishes a markdown file at its own root telling outside agents how to register on behalf of a user. This site has served a file at that same address since June. The two are not the same document, I read both on 4 September to find out how far apart they are.

What each document asks for

The scanner this site is measured by publishes its own recipe for the check it calls authMd, at https://isitagentready.com/.well-known/agent-skills/auth-md/SKILL.md, which answered 200 with 2 112 bytes. It asks for a markdown file at the service root with an H1 containing auth.md, protected resource metadata carrying resource, authorization_servers, scopes_supported and bearer_methods_supported, and an agent_auth block in the authorization server metadata. It names that block's fields: skill, register_uri, claim_uri, revocation_uri, identity_types_supported, identity_assertion.assertion_types_supported and anonymous.credential_types_supported.

The WorkOS file format at https://workos.com/auth-md/docs/auth-md asks for the same two-hop discovery walk and the same agent_auth block. It names the block's fields identity_endpoint, claim_endpoint and events_endpoint.

So the two documents agree on the path, the file name, the H1 and the discovery order, and they nearly agree on the protected resource metadata: the scanner asks for four fields in it and WorkOS for those four plus resource_name. They disagree on what to call the registration endpoint, the claim endpoint and the revocation surface inside the block both of them require.

Why that is worth knowing before you implement

A site built from the scanner recipe and a site built from the WorkOS specification both serve a file called auth.md at the root, both publish an agent_auth block, and both can be described as having implemented auth.md. An agent that fetches one and looks for the other's field names finds nothing where it expects an endpoint. Nothing in either document warns you, because each is internally complete and neither cites the other.

The gap is easy to walk into in one direction in particular. If you build against the specification and then test with the scanner, the check reports the file as missing rather than as differently named, and the natural reading of that result is that the file is not being served.

What this site does

This site follows the scanner's naming, because that is what was measurable when the file was written and because a rename would drop a check this site's own score rests on. The file is at https://turva.dev/auth.md, served as text/markdown, and the protected resource metadata carries all five fields the WorkOS discovery step names.

What this site does not implement is both of the WorkOS ceremonies. Agent verified needs an identity provider to vouch for a user, and user claimed needs a device-code confirmation. Neither exists here for the same reason: there are no user accounts, every resource is public and read only, and nothing on the domain answers 401, so there is no challenge for an agent to bootstrap from. The file now says that in its own words rather than describing a flow that is not there, and it names the protocol so a reader can see the difference for themselves.

The word claim is its own trap. On this site it means proving control of an identifier you already corresponded under. In the protocol it means a ceremony where the agent shows the user a code to confirm in a browser. Same word, two mechanisms, and the file now separates them.

What I am not claiming

I have no view on which naming should win, and this is not a prediction that either one becomes a standard. I did not measure how many sites serve an auth.md of either kind, so nothing here says which is more common. What I read is two published documents on one day, and what I can show is that they name the same three positions differently. Anyone implementing from one and verifying against the other will find that out the hard way, and it seemed worth writing down before more sites are built either way.

Frequently asked

Is auth.md a standard?

No. It is a convention published by two parties who do not agree on the field names inside it. The underlying pieces it composes are standards, OAuth protected resource metadata in RFC 9728 and authorization server metadata in RFC 8414, and those two are the parts an agent can rely on today.

Which field names should I use?

That depends on what will read your site. If a scanner grades you, use the names its recipe publishes and verify with the scanner. If a specific agent platform will consume the file, use the names its specification publishes. There is no third answer that satisfies both, and the honest thing is to say in the file which one you followed.

Does a site need an auth.md at all?

Only if an agent could ever need permission to do something there. A site that is entirely public and issues no credentials can publish one to say exactly that, which is what this site does, but there is nothing dishonest about not having the file when there is nothing to authenticate.

Originally published at https://turva.dev/blog/two-auth-md-dialects

What four AI assistants call an agent readiness audit

Erik Rekola — Fri, 04 Sep 2026 04:57:08 +0000

On 3 September 2026 fifty buyer questions were put to ChatGPT, Gemini, Perplexity and Google AI Mode from an anonymous browser session, one run per question, 193 answers in all. The questions are the ones a buyer types: what an agent readiness audit is, what it costs, who does it in Finland, how it differs from SEO. Claude was not measured, because its answers sit behind a login and the instrument runs logged out.

Two products share the words

Eleven of the fifty questions use the words agent readiness, or agenttivalmius in Finnish, without saying whether they mean a website or a company. Those eleven got 41 answers. Eighteen of the 41 described the readiness of an organisation to deploy AI agents: its data, its governance, whether its teams are prepared. Thirteen described what this site means by the words, whether a website and its APIs can be read and acted on by an agent. Six described both, and four could not be placed.

The split is not even across assistants. Gemini gave the organisational reading in eight of its eleven answers and Google AI Mode in six of nine. Perplexity was the only one that leaned the other way, five of eleven for the website reading, and it was also the one that named this site most often, five times against three for ChatGPT and one each for the other two. ChatGPT split evenly, three answers for each reading and three for both, with one unclear.

The words are the problem, not the assistants

Two Finnish questions in the set name the website outright or avoid the word agenttivalmius. All seven answers to those two read the question as being about the website. The assistants have no trouble with the concept once the question carries it. What drifts is the bare term, and it drifts toward the organisational meaning. The likely reason is what the assistants have read, because that meaning appears in far more published text, but this run does not measure that, and the control set is seven answers, so read it as the direction and not the proof.

That shows in who gets named. Thirty-five of the 41 answers named at least one provider, 112 different names between them, and almost none repeated. Both kinds of answer named a long tail of small consultancies and scanners with agent readiness in the brand, most of them once. The organisational answers also named large consultancies, and the Finnish questions a few Finnish agencies. Across all 193 answers this site was named in 27, and 23 of those carried a link to it.

What follows from it

For a buyer, one question settles it: ask the provider what the report reads. If the answer is the organisation, its data and its teams, that is a strategy engagement. If the answer is the website and the API, the files an agent fetches and the data it gets back, that is the audit this site sells, and the report should name the checks. Both are real work. They are not the same work, and a proposal that does not say which one it is has not said much.

For this site, the same finding turned into one sentence. The FAQ on the services page and the home page now says that the audit reads the website and its APIs and not the organisation's readiness to adopt agents, and llms.txt says the same in its summary, so an assistant that reads either gets the distinction in the first lines. Whether that moves the answers is what the next run of the same fifty questions will show, and it will be reported the same way.

Frequently asked

Is an agent readiness audit about the company or the website?

Both services exist under the same words. The audit on this site reads the website and its APIs with an independent scanner and reports per check. An organisational agent readiness assessment reads a company's data and governance and how prepared its teams are. Ask a provider which report they deliver.

Why do AI assistants describe the organisational version more often?

In a measurement of 41 answers on 3 September 2026, 18 described the organisational reading and 13 the website reading. When a question names the website, all seven answers in the control set read it that way, so the drift sits in the bare term and not in the assistants' ability to read the website meaning. Why the bare term drifts was not measured.

How was this measured?

Fifty buyer questions, four assistants, one anonymous run per question on 3 September 2026, 193 answers. Each answer was read for how it interpreted the term, whom it named and whether it named this site. Claude was not measured because it requires a login.

Corrected 2026-09-04. The version served for the first seven hours said Perplexity was the only assistant that named this site more than once and offered an unmeasured reason for the drift of the term. Perplexity named it most often, five times against three for ChatGPT, and the reason is now stated as unmeasured. The counts did not change.

Originally published at https://turva.dev/blog/what-ai-assistants-call-an-agent-readiness-audit

Thirty days after the brief: 210 sites rescanned, four moved

Erik Rekola — Fri, 04 Sep 2026 04:56:44 +0000

Every brief I send, a short written reading of one company's website that goes out unasked, carries the same promise. Thirty days later I run the same scanner on the same site again and send back what changed, whether or not anyone answered. Between 19 August and 3 September that promise came due for 210 sites, first measured between 18 July and 6 August, and this is the first time the rescans are read as one set.

What was measured

The scanner is isitagentready.com, which grades a site from Level 0 to Level 5, run against the same host with the same default profile as the first time, twice per site, and a pair that disagrees is run again until the reading settles or is recorded as unstable. A site counts as moved when its level changed. A check that started passing while the level held is recorded in the file but not counted here, because the level is what the recipient was told in July and what the rescan message reports.

210 sites rescanned. 201 gave a reading that can be compared with the first one.
Nine could not be compared. Two hosts answered the scanner with 403 and one answered 500, and two of those three had done the same in July, so they never had a first reading either. Four runs did not settle into a reading, one of them because a single header check stalled four times out of four. Two were not rescanned at all, because the record had no address to send the result to.
197 of the 201 read the same level as in July. Three moved up and one moved down, 2,0 percent.
Seven of the 210 had replied to the brief by the time of this count, 3,3 percent.

The four that moved

Three went up. A site whose sitemap answered 404 in July answers 200 now, and reads Level 1 instead of Level 0. A site whose robots.txt redirected to itself and whose sitemap returned 500 has both working, Level 0 to Level 1. A site that now declares Content Signals in its robots.txt reads Level 2 instead of Level 1. One went down: its sitemap answered in July and answers 404 now, Level 1 to Level 0, confirmed with a request outside the scanner so that a scanner artefact is ruled out.

None of the three that moved up had replied to the brief. So the brief cannot claim them, and I am not going to. The likelier explanation is ordinary maintenance, a CMS update or a plugin that started generating a sitemap, and that is worth writing down because a rescan series is the exact place where a consultant is tempted to count every improvement as an effect.

The scanner moved too

During the series the scanner added a check named ard to its API group. The twelve sites measured in the first days of September were read against a larger check set than in July without their sites changing. A rescan therefore compares the denominator first and the passes second, and the message the recipient gets names the checks rather than a percentage, because a percentage over a moving denominator says nothing.

What this says and what it does not

The sample is my own prospecting list, sites I chose to write to, not a random draw. So 2,0 percent is a fact about these 210 sites and not a rate for the web. Zero movement in thirty days is also the expected result when nobody has decided to act. The fixes are small, a sitemap line, a robots.txt group, a header, but they need a person who owns the website to schedule them, and one unsolicited email rarely does that inside a month.

What the series does show is narrower and still useful. The promise has been kept for these 210 sites. The scanner is stable enough to compare across a month for 201 of them, and where it is not, the reason can be named, on the host side for most of the nine and in my own records for the two that had no address. And the one site that went down is a reminder that agent readiness is not a state a site reaches once: a sitemap that disappears in an update takes the level with it, and nobody notices until something reads the site as a machine.

292 promises are still open, the next of them due on 9 September. When the set is larger the same reading will be repeated.

Frequently asked

What does the 30 day rescan promise mean?

Every brief turva.dev sends says that the same scanner will be run on the same site thirty days later and the result sent back, whether or not the recipient answered. The rescan message names the checks that changed rather than a percentage, because the scanner's check set can change in between.

Did the briefs change anything in thirty days?

Four of 201 comparable sites changed level, three up and one down, and none of the three that moved up had replied to the brief, so the change cannot be attributed to it. Ordinary maintenance is the likelier cause.

Why could nine sites not be compared?

Two hosts answered the scanner with 403 and one with 500, four runs did not settle into a reading, and two were not rescanned because the record had no address to send the result to. A rescan compares two readings, and where one of them is missing there is nothing to compare.

Corrected 2026-09-04. The version served for the first seven hours said the first measurements began on 13 July, described the nine unreadable sites less precisely, and claimed the promise "can be kept at this volume". The earliest first measurement was 18 July, the nine are now broken down as measured, and the claim is limited to these 210 sites. The counts did not change.

Originally published at https://turva.dev/blog/thirty-days-after-the-brief

Website agent readiness, measured on 567 company sites

Erik Rekola — Thu, 03 Sep 2026 09:35:30 +0000

In July I wrote up sixteen Finnish B2B sites. Since then the same measurement has run over every company I have written to, and the sample is now 567 company sites, measured between 28 June and 3 September 2026. The scanner is the same one, isitagentready.com, which grades a site from Level 0 to Level 5. The sample is still my own prospecting list and not a random draw, so read it as a large snapshot rather than a census.

Key figures

567 company sites, 407 Finnish and 160 from elsewhere, one independent scanner.
Level 1 of 5: 485 sites, 85,5 percent. Level 0: 74 sites, 13,1 percent. Level 2: 7 sites, 1,2 percent. One site read Level 5.
The Finnish and the non-Finnish subsets read the same: 86,5 and 83,1 percent at Level 1.
In my own first-fix notes for the Level 0 sites, robots.txt and the sitemap are the two most frequent subjects.
No company is named here. Every level is the reading on the day I wrote to that company.

What website agent readiness means

The phrase agent readiness is used for two different things, and AI assistants currently answer the question with the other one. Ask an assistant what an agent readiness audit is and the answer describes an organisation: its data, its governance, whether its teams are ready to deploy AI agents. That is a real question, and it is a different one.

Website agent readiness is a property of a site or an API. It asks whether a machine reading on someone's behalf can find the site, read its pages without a browser, learn what the company sells, and act on that through a declared interface. An independent scanner can measure it, and the result is a number a third party can check. That is the measurement below.

The numbers

Of the 567 sites, 485 read Level 1 of 5. Level 1 is the floor an ordinary CMS site reaches. Seventy-four sites read Level 0, below that floor. Seven read Level 2, and one read Level 5.

The Finnish subset is 407 sites, and 352 of them, 86,5 percent, read Level 1. The 160 sites from outside Finland read 83,1 percent at Level 1 and 14,4 percent at Level 0. The two subsets read the same, so the floor is not a Finnish trait.

The scanner added one check to its set during these ten weeks, so the two ends of the period are not measured on an identical instrument. The level scale did not change. The thirty-day rescans I promise each company are a separate series and are not in these figures.

What the Level 0 notes say

For each site I wrote down the single sharpest finding, the thing I would fix first. Sixty-eight of the 74 Level 0 sites have such a note. Robots.txt appears in 45 of those notes and the sitemap in 38, and 29 notes mention both. The pattern in those 29 is a robots.txt the CMS shipped by default and a sitemap that is either missing at every standard address or never announced in robots.txt, so an agent that follows the rules gets no list of pages to read. These sites work for a person. A person does not start from the sitemap.

The 439 Level 1 sites with a note are more varied. The sitemap appears in 102 notes, llms.txt in 99, robots.txt in 72, structured data in 49 and an MCP server in 35. Level 1 is where the site can be found and the rest is missing, and the rest is where the work is.

Why the level is the useful number

A level from an independent scanner is a claim someone else can verify. Run the same scanner on the same site and you get the same reading, or a newer one that shows what changed. That is the only reason I publish my own score, and it is why every company I wrote to got the level on the day of writing and an offer to read it again thirty days later.

Four levels separate the typical company site from a site an agent can read and act on, and the gap is mostly mechanical: serve markdown next to HTML, publish structured data, publish an llms.txt that lists real pages, expose the discovery files, and answer on the endpoints they declare. That is web development with a checklist, and it can start before anyone writes an AI strategy.

How to read your own site

Run isitagentready.com on your domain and read the level, then read which checks failed. The free llms.txt validator at https://turva.dev/llms-txt-validator reads the llms.txt part in more detail. If you want the whole surface read and the fixes listed in priority order, the agent readiness audit is described at https://turva.dev/services, and the way to start is an email to info@turva.dev with the domain.

Frequently asked

Are these 567 sites broken?

No. They load and a person can use them without trouble. The level measures something else, whether a machine reading on someone's behalf can find the site, read it without a browser, learn what the company sells and act on it. Level 1 is where most working company sites sit today.

Why do Finnish and other sites read the same?

Because Level 1 is what a CMS ships by default: a robots.txt, a sitemap and HTML pages. Nothing in that default was built for agents, and no country's CMS market ships more than that, so the floor is the same wherever the company is.

How do I check my own site?

Run the scanner on your domain and read the level, then read which checks failed. The free llms.txt validator on this site reads the llms.txt part in detail. The audit reads the whole surface and lists the fixes in priority order, and it starts with an email carrying the domain.

Originally published at https://turva.dev/blog/website-agent-readiness-567-sites

TRACE signs how an agent ran, not what it was allowed to reach

Erik Rekola — Sun, 30 Aug 2026 08:53:41 +0000

The Linux Foundation now governs TRACE, short for Trust, Runtime Attestation and Compliance Evidence. OPAQUE contributed the specification, announced on 25 August 2026, and developed it together with AMD, Intel, Microsoft and the Technology Innovation Institute. The idea is one signed artifact, called a Trust Record, that says which model ran, on what hardware, under which policy, against which class of data and which tools it called. The point of signing it inside a trusted execution environment is that the operator cannot write it afterwards. An ordinary audit log is written by the system being audited. This one is not.

That is a real distinction and it is the same distinction my own work rests on. A number someone reports about themselves is a claim. A number a third party can check is evidence. TRACE moves runtime logging from the first category toward the second.

Then I read the project's own documentation instead of the press release, and the interesting part is what the specification refuses to promise.

The level is the claim, not the name

TRACE has three trust levels and they are not close to equivalent.

Level 0 is software-only signing. The project writes that a privileged operator with root access can produce a valid-looking Level 0 record for a run that never happened, or that violated policy. The documentation puts Level 0 in development, internal audit trails and staging environments, and says so plainly.

Level 1 requires the record to be signed by a key generated inside a verified TEE, with a non-zero measurement of the launch state and a verifier that has actually checked the quote. This is where hardware-rooted starts meaning something.

Level 2 adds a SCITT transparency log entry at a resolvable address, so a third party can check later that the record has not been altered since it was logged. It still does not prove that every field in the record was correct in the first place.

So "we use TRACE" is not a statement about assurance. The level is the statement, and a vendor who names the standard without naming the level has told you nothing. Anyone who has read an agent-readiness score without the scanner and the level next to it will recognise the shape of that problem.

Two limits worth knowing before anyone builds on this

The specification is honest about both, which is more than most standards manage.

Revocation is the place where the project's own two documents pull in different directions. They agree on the underlying fact. A signature stays mathematically valid forever, so a record signed by a key that has since been revoked keeps verifying on a machine with no network. The limitations page then says the verifier has to consult current revocation status at verification time and calls that an online step by definition. The specification says close to the opposite and says it by design: revocation statements are anchored in the same transparency log as the records they govern, verifiers cache a signed revocation bundle carrying an expiry, and the text describes this as deliberately replacing a status endpoint that would require a callback. Which behaviour you get depends on which of the two a given implementation followed, so ask. Both documents agree on the fallback, and it is the sane one. A verifier holding no revocation bundle, or only an expired one, reports that instead of treating it as a pass.

Platform state is not appraised. On the AMD path the verification chain checks the report signature and the certificate chain from the VCEK up to a root the operator pins, and it checks the measurement binding. What it has no field for is the state of the machine that produced the report. As the documentation puts it, a verifier reading a conformant claim cannot appraise platform state even when the producer did check it.

Neither of these makes TRACE useless. They make it a layer with edges, and knowing where the edges are is the whole job when you are the one signing off.

The half TRACE does not cover

A Trust Record proves how an agent ran. It says nothing about whether the systems that agent touched were readable to it, whether the tool it called should have been callable at all, or whether the decision boundary around it was written down anywhere.

That is the split I keep running into. Attestation is evidence about execution. Agent-readiness is evidence about the surface: whether your site, your data and your endpoints answer a machine the way they answer a person, and whether the permissions around them are something you can point at rather than something living in one engineer's head. An organisation can have a perfect Level 2 record of an agent doing exactly the wrong thing, correctly, against data it should never have been given.

Both halves are receipts. They are receipts about different questions.

What this is worth today

The specification is a developer preview. Version 0.2 is current and the draft says its fields and conformance requirements may change before v1.0. The download figure in the announcement is the contributing vendor's own number and it counts installs, not deployments, so it is not evidence of adoption. Treat all of that as a snapshot of this month, exactly as you should treat any number I publish about my own site.

The part that is already useful is the vocabulary. If you run agents against production data, the question to ask a vendor is not whether they support TRACE. Ask which level their records reach, whether their verification checks revocation, and what happens to the answer when the network is down. Those three questions are answerable today and they do not depend on the specification reaching v1.0.

For EU buyers there is one more concrete hook. The project states that Level 0 does not satisfy the tamper-evident logging requirement of EU AI Act Article 12, and that DORA Article 9 needs Level 1 or above with transparency log anchoring. If someone shows you a compliance story built on software-only signing, that gap is written down in the specification's own limitations page.

Sources: Linux Foundation press release, 25 August 2026, TRACE v0.2 specification, TRACE trust levels, TRACE known limitations, trace-spec on GitHub.

Originally published at https://turva.dev/blog/trace-runtime-attestation

I scanned fourteen code hosts. Not one served an MCP server card.

Erik Rekola — Sat, 22 Aug 2026 12:40:10 +0000

Cursor launched Origin on August 17 and calls it a Git forge for the agentic era. I ran an independent agent-readiness scanner over its public surface and over thirteen other code hosts on August 22. Not one of them reached Level 2 of 5.

Key figures

Fourteen code host surfaces scanned with the isitagentready scanner on 2026-08-22, one run each.
Highest reading was Level 1 of 5. Six surfaces reached it, belonging to Cursor Origin, GitLab, SourceForge, Forgejo and Azure DevOps. The other eight read Level 0.
The scanner group named API, Auth, MCP & A2A Discovery holds nine checks. Across the sample it ran 124 times and passed twice.
Zero MCP server cards, zero API catalogs, zero agent skills indexes, zero ARD manifests and zero auth.md files across all fourteen. GitLab answered 403 rather than 404 on most of those paths. The A2A card and WebMCP checks completed on thirteen, and both read zero there.
Both passes were OpenID Connect metadata, which is published so people can log in and not so agents can find anything.

What was measured, and what was not

The scanner reads a public web surface. It does not log in, and it does not see a repository. Origin itself sits behind a Cursor paid plan, so the reading describes cursor.com and its marketing page for Origin, not the forge. Four targets redirected somewhere else, GitLab to its marketing site and Azure DevOps to a Microsoft product page, so GitLab was measured a second time from the application at gitlab.com/explore. Both readings landed at Level 1, with different checks passing on each.

One host is missing from the count. savannah.gnu.org did not answer on two attempts, once with a network error and once with a 502, and an unreachable site is not a zero.

For scale, my own site reads Level 5 of 5 on the same scanner on the same day. That comparison is not a fair fight and I am not presenting it as one. turva.dev is a one-person advisory site with sixty canonical pages, and a code host carries multi-tenant load plus an access model that a site like mine never has to solve. It does show that the manifests in question are not expensive to publish.

The numbers

Host	Level	Checks passed
cursor.com/origin	1/5	3
gitlab.com marketing	1/5	4
gitlab.com/explore	1/5	4
sourceforge.net	1/5	3
forgejo.org	1/5	3
dev.azure.com	1/5	3
github.com	0/5	2
bitbucket.org	0/5	2
sr.ht	0/5	2
gitea.com	0/5	3
gitee.com	0/5	2
launchpad.net	0/5	3
radicle.dev	0/5	3
gerritcodereview.com	0/5	1

For almost every host the passing checks were the same two, a robots.txt the scanner reads as valid and a robots.txt whose rules reach AI crawlers, either by naming them or by letting the wildcard cover them. That is the floor an ordinary site reaches without trying. Gerrit sits below it, because its robots.txt carries no User-agent line at all, so the file is read as invalid and the AI rules check falls with it.

GitHub runs an MCP server. Nothing on github.com says so.

This is the finding I keep coming back to. GitHub operates a production MCP server, and I used it on the same day I ran these scans. It works. But github.com serves no MCP server card, no API catalog and no Link header pointing at either, so an agent that arrives without being told about the server has no way to discover it. The capability exists and the announcement does not.

The same shape repeats across the sample. What follows is a reading of how these products are sold, which the scan does not measure. Several of them are sold as the place where agents work on code, and on every one of them the way in is a docs page written for a person.

Three things the scan does not prove

GitLab answered HTTP 403 to most of the well-known paths, including the API catalog, auth.md, the MCP card, the A2A card, the skills index and the ARD manifest. A 403 is a refusal, not evidence that a file is absent, and I have recorded those as failures only because the check got no answer.

Two checks did not complete on Gitee, and for different reasons. The A2A card fetch aborted and the WebMCP check timed out at eight seconds. Its discovery group was therefore scored on seven of nine.

The sample is fourteen surfaces I picked by hand. It is not a random draw and it does not cover every code host. Read it as a snapshot of one day.

Why any of this matters

An agent that lands on a code host today can read the marketing copy. It cannot ask the site what it is able to do, because nothing on the site answers that question in a format an agent parses. Every integration therefore has to be hard-coded by a human who already knows the endpoint exists.

The fixes are small and mostly mechanical. A server card is a JSON file at a known path. An API catalog is a linkset. A Link header is one line of response configuration. None of it requires rebuilding a forge, and none of it had been done on any of the fourteen surfaces I measured.

If you want to check a site yourself, the scanner is public and the free llms.txt validator is at turva.dev/llms-txt-validator. The audit and advisory work is at turva.dev.

Frequently asked

Does this mean GitHub is broken?

No. GitHub works, and so does its MCP server, which I used on the same day I ran the scan. The reading describes one thing only, whether the site announces what it can do in a format an agent finds without being told. On that point github.com reads zero, and so does every other host in the sample.

Why would a code host publish an MCP server card?

So that an agent arriving at the domain can learn that a server exists, where it is and what it does, without a human pasting the endpoint into a config file first. The card is a JSON file at a known path. It does not change the forge and it does not expose anything the docs do not already say.

How do I check a host myself?

Run the same public scanner against the domain and read the group named API, Auth, MCP & A2A Discovery. The result is a snapshot of that day, mine included, because these specifications move month to month.

Originally published at https://turva.dev/blog/agent-readiness-code-hosts

It would be cheating to keep the old price

Erik Rekola — Fri, 21 Aug 2026 12:34:20 +0000

The agent-readiness audit is now €4,300 and two weeks. It was €6,500 and two to three weeks. Nothing came out of the scope to pay for that.

The scanner is the same one, isitagentready. The manual checks that sit over the scanner are the same. The re-scan after the fixes is still the thing the engagement is judged on, and it is still the only claim I make about the result.

What moved is that the part the old price charged for twice is now written down once.

What the old price charged for twice

An audit has two halves. One half is measuring a surface: run the scanner, read what it says, check by hand whether the number is telling the truth. That half is real work and it stays.

The other half was me deciding, again, what a passing row actually looks like. Twenty-two checks, each one an open specification that moved in the last year, and for each one the question was the same: what does a correct implementation of this look like, what does the scanner accept, and what is the concrete change that flips it. I answered those questions from scratch every time, and the old price charged for the answering as well as the measuring.

That is the half that is now a file. The checklist has 42 rows. Every row names the pass condition, points at a working implementation of that row on a live surface, and links the fix recipe. There are 25 recipes behind it, one per check or close group.

The live surface the rows point at is this site, because it passes every scored check and I can show the code for each one.

What it cost to get there

I read my own workspace file by file over seven days in August and recorded 367 findings. That was written up at the time. Since then the same treatment went to the four repositories at byte level, and then to the folders and documents, and then three verification rounds ran over the folder audit and the session before it.

The folder and document audit removed 2 317 files and 116 622 446 bytes. Not one line of source was in what went. It was temporary renders, build caches, a dependency tree and six revision copies of one file. I am not quoting a before and after total for the workspace, because three measurements of it taken the same day differ by up to 39 281 bytes: tools write into the folder that was supposed to be the anchor, so that total is not a number anyone should cite.

Three sessions did that work: 2 254 messages, and about 366 million tokens as the raw sum. Weighted the way billing weights them, where a cache read is a tenth of a fresh input token and an output token is five, it comes to about 88 million.

Across every session recorded on this machine the raw sum is 7 197 173 453 tokens, and the weighted figure is 1 849 081 095. Those totals are a floor rather than a count. The transcript tree holds 25 days, and a disk restore in August took five weeks of it with it, so the missing period is missing from the number too.

That spend is mine. It produced no invoice and it was never billable. What it produced is the file that means the next audit does not repeat it. Keeping the old price and the old clock would mean charging a client for work that is already done.

Why the accuracy does not drop

The obvious reading of a lower price and a shorter clock is that something got smaller. What happened is the opposite, and the checklist proved it on me before it proved it on anyone else.

Writing the checklist out found a hole in my own material. The scanner scores a check called ard, the capability manifest at /.well-known/ai-catalog.json. My own recipe index named 21 checks and that one was not among them, and no recipe covered it. My own gate did not catch it either, because the gate reads the checks a recipe claims and has nothing to say about a check with no recipe at all. An audit run from that index would have skipped a scored check and still looked complete.

That is one check out of 22, on a site that serves the manifest correctly and passes the check. It was invisible for as long as the method lived in my head, and it was visible as soon as the method became a list.

A shorter engagement also removes a real source of error. Two to three weeks is long enough for the specifications to move underneath the report, which has already happened here. A payment specification dropped in a point release the extension that three of my guides described, and the MCP server card proposal moved onto an extensions track while the sentence about it stood still. Two weeks leaves that less room. It does not remove it.

What these numbers do not prove

Between the two windows the transcript tree records, the weighted cost per message fell from about 69 700 to about 41 100 tokens. It is tempting to read that as the cleanup paying for itself, and I am not going to claim it. The two windows are five weeks apart, the models in them are different, and the mix of work is different. The drop is real in the record and its cause is not established, so it is an observation and not evidence.

The checklist has also not yet run against a client surface. It was built from 13 rounds of reading my own, which is a real basis and a narrow one.

What is unchanged

Fixed scope, written before any payment. Async only, no calls and no calendar links. Read access is enough, production credentials are not requested, and write access is scoped per task only if implementation is bought separately. The report names 3 to 10 fixes in order of impact, and the next scan either reads higher in the categories the report named or the report explains which tradeoff was kept on purpose.

The other prices did not move. The Shopify agent storefront check is €1,900 within 48 hours of a written kickoff, advisory is €3,000 per month with a three month minimum, and implementation is €1,500 per day. All prices exclude VAT.

The scope is agreed in writing first. I reply by email within one business day.

Frequently asked

Does a lower price mean a smaller audit?

No. The scanner is the same one, the manual checks over it are the same, and the report still names 3 to 10 fixes in order of impact with a re-scan that verifies them. What got shorter is the part where I work out from scratch what a passing check looks like, which is now a written checklist of 42 rows.

What does an agent-readiness audit cost?

€4,300, fixed scope, two weeks, VAT excluded. The other prices did not move: the Shopify agent storefront check is €1,900, advisory is €3,000 per month with a three month minimum, and implementation is €1,500 per day.

How long does the audit take?

Two weeks from the agreed written kickoff. It was two to three weeks, and the shorter window also leaves the specifications less time to move underneath the report.

How do you know the accuracy held?

Writing the checklist out immediately found a scored check, ard, that was missing from my own fix recipe index and from my own gate. That is the kind of hole the list exists to catch, and it caught it on me first.

Corrected 2026-09-03. Three sentences in this post read as if a client had already paid the old price. None had: the audit had not sold at €6,500. They now say what the old price charged for. Nothing else in the post changed.

Originally published at https://turva.dev/blog/cheating-to-keep-the-old-price

I thought it was a small job

Erik Rekola — Sun, 16 Aug 2026 20:55:55 +0000

I set out to read my own workspace file by file. The idea was that it would take an evening. It took seven days, and it produced 367 findings across nine packages.

What was actually read

The workspace holds 2 307 text files and 28 826 789 bytes, which is roughly 8 million tokens. Another 441 files are binaries such as images and PDFs. They were counted but not read line by line, because reading a JPEG line by line means nothing. The nine packages split that by surface: the Worker source, the rest of the site repo, the MCP server and the validator package, the tools, the two large decision logs, the knowledge base, the agent memory, the docs and cross-post trees, and the scratch folder.

Seven days of that produced 69 recorded decisions and 50 new entries in the trap log. It produced no invoice, no proposal and no sent message.

That is the honest ledger. A week of work with nothing billable in it.

What it bought

The base is now audited file by file, and it is not audited by me remembering that I checked it. Seven deterministic gates run on my machine as editor hooks and block the action rather than warn about it. They stop the edit tool in this workspace, git in the agent shell, generated files written to the workspace root, and repo edits made before the trap log has been read. Two of them run after a write and check for NUL bytes, changed line endings and a size collapse.

Twenty-three gate scripts sit in the toolchain and run on demand or on ship. Three of them run on every release, and between them they perform 314 mechanical checks with no network and 567 when the live URLs and the manifest signatures are included. None of those numbers is a target. They are just what the scripts count when they run.

What a line-by-line read finds that a scan does not

One measurement was written into two documents from the same run, one saying the worst overflow was 458 pixels and the other 514. Only 514 is internally consistent with the 139 pixel figure both texts also carry, so one of them had been wrong since the day it was written, and no gate could see it because both numbers were plausible.

A dependency update moved a package to a new version, and the allow list that permits that package to run its install script was pinned to the old version by name. The install script stayed blocked. Nothing broke, which is why it would have kept not breaking until something did.

A grid track refused to shrink below 412 pixels inside a 336 pixel row, because 1fr means minmax(auto, 1fr) and auto resolves to the widest unbreakable child. That one pushed the home page sideways at 200 percent text zoom, and I fixed the wrong cause three times before measuring instead of guessing.

What this does not prove

It does not prove the workspace is correct. It proves that 367 specific things were read and classified. Each one was then either fixed or written down as a decision with a reason. A gate that is green tells you what it checked, and the useful question is always what it did not check.

It also does not prove the week was worth it. That depends on whether the next audit I sell is better because of it, and I do not know that yet.

Originally published at https://turva.dev/blog/i-thought-it-was-a-small-job

AI agent use cases

Erik Rekola — Fri, 07 Aug 2026 09:00:00 +0000

An AI agent is useful wherever data moves and a decision follows. It reads a machine-readable surface, decides inside the limits it was given, and acts on what it finds. The cases below are grouped by what the agent does, not by industry, because the same pattern repeats across all of them.

Commerce and transactions

An agent reads a product catalog, weighs the options against a buyer's constraints, and completes a checkout through a protocol rather than a form. The work is making the offer, the price, and the checkout legible and reliable enough for the agent to finish without a human in the loop.

Monitoring and response

An agent watches an API, a feed, or a system and acts the moment a threshold is crossed, with no one having to be watching. The work is a clean data path so the signal arrives in time, and a tight envelope so the agent takes only the actions it is allowed to.

Field and frontline support

An agent guides a person doing physical work, drawing on the same data an expert would and answering from it in the moment. The agent extends the expert's reach instead of standing in for the person at the far end.

Operations under bad connectivity

An agent runs a remote system over a link that drops, holding its last safe state and resuming cleanly when data returns. This is where the data path matters most, because one lost packet can stall every decision queued behind it.

Back-office and data work

An agent reconciles records across systems, flags only what does not match, and routes the rest. The value is consistency, a decision the agent makes the same way every time, with a trail you can audit afterwards.

Autonomy at the edge

An agent makes a time-critical call locally, where the round trip to a human is too slow to matter. The decision has to sit inside rules agreed in advance, because there is no one to ask. The fields that already live with hard time limits learned that discipline early.

The common thread

These are examples, not a closed list. The same discipline carries from one case to the next. The question is rarely whether an agent could do the work. It is whether the data reaching it is clean and the envelope around it is set, because those two decide whether the agent makes the right call or a fast wrong one.

If you want an agent to do one of these reliably, or to measure how ready your site or API is for agents in the first place, contact info@turva.dev.

Originally published at https://turva.dev/guides/ai-agent-use-cases

Common agent-readiness gaps on marketing sites

Erik Rekola — Thu, 06 Aug 2026 09:00:00 +0000

Most marketing sites are strong for people and weak for agents, and the gaps are predictable. A readiness review tends to find the same handful of misses, each of which quietly removes the site from an agent's view.

The first is rendering. A site that builds its content with JavaScript returns an empty shell to an agent, so the content never arrives in the first response. The second is discovery. No llms.txt and a thin or missing sitemap, so an agent has nothing to read but rendered pages. The third is cost. Only HTML is offered, with no markdown form, so an agent spends its budget on markup and truncates the page.

Beyond those, capability is usually undeclared. The site may have an API or a useful action, but with no server card or OAuth discovery, an agent cannot find or use it. Structured data is often missing too, so prices and facts are left for the agent to infer from layout.

None of these are hard to fix, and that is the point. The work is mostly at the edge and in a few small files, and the result shows up immediately in a scanner. A site does not have to rebuild to become legible to agents, it has to publish what agents already look for.

turva.dev runs this exact review and reports each gap with a concrete fix. For an audit, contact info@turva.dev.

Originally published at https://turva.dev/guides/agent-readiness-gaps

DEV Community: turva.dev

I rebuilt turva.dev around the report

What changed on the site

What the report template has to carry

The finding that changes no scanner points

A smaller report for a Shopify question

What I can claim about the update

Frequently asked

Related

What 19 identity vendors publish for agents

How this was measured

The column where every one of them scored zero

The smaller readings

One site where 200 means nothing

What this does not say

Why the companies are not named

One last thing, and it cuts against me

Frequently asked

Related

Two files called auth.md, and they disagree on the field names

What each document asks for

Why that is worth knowing before you implement

What this site does

What I am not claiming

Frequently asked

Related

What four AI assistants call an agent readiness audit

Two products share the words

The words are the problem, not the assistants

What follows from it

Frequently asked

Related

Thirty days after the brief: 210 sites rescanned, four moved

What was measured

The four that moved

The scanner moved too

What this says and what it does not

Frequently asked

Related

Website agent readiness, measured on 567 company sites

Key figures

What website agent readiness means

The numbers

What the Level 0 notes say

Why the level is the useful number

How to read your own site

Frequently asked

Related

TRACE signs how an agent ran, not what it was allowed to reach

The level is the claim, not the name

Two limits worth knowing before anyone builds on this

The half TRACE does not cover

What this is worth today

Related

I scanned fourteen code hosts. Not one served an MCP server card.

Key figures

What was measured, and what was not

The numbers

GitHub runs an MCP server. Nothing on github.com says so.

Three things the scan does not prove

Why any of this matters

Frequently asked

Related

It would be cheating to keep the old price

What the old price charged for twice

What it cost to get there

Why the accuracy does not drop

What these numbers do not prove

What is unchanged

Frequently asked

Related

I thought it was a small job

What was actually read

What it bought

What a line-by-line read finds that a scan does not

What this does not prove

Related

AI agent use cases

Commerce and transactions

Monitoring and response