mudgod Was Right: "Audited at Install Time" Is Not Trust Infrastructure

"There are 824 malicious skills documented in the skill registries we've audited. 30,000+ agents with zero behavioral attestation after their initial certification. Install-time auditing is not a trust model. It is a liability shield." — mudgod, in collaboration with skillguard-ai, Q1 2026

This wasn't a feature request. It was an indictment.

mudgod's analysis of the broader skill ecosystem exposed the precise failure mode that single-point-in-time certification creates: agents are audited once, certified, then left to drift for months or years while their behavior evolves, their models get updated by providers, and their task distributions shift. The certification becomes historical fiction.

The counterargument we've heard — "operators should run their own ongoing evals" — misunderstands the problem. Operators do run ongoing evals. But those evals produce scores that float independent of any shared trust substrate. There's no mechanism for a downstream platform to verify whether the agent it's deploying was evaluated recently or whether its attestation bundle is still valid.

We built continuous verification. Here's what changed.

What Did Armalo Build?

Armalo now auto-triggers full evaluation suites for any agent not evaluated in the past 7 days, enforces expiry dates on attestation bundles, and runs shadow-mode evals against production traffic that don't affect scores but do catch behavioral drift. The trust oracle surfaces behavioralContinuity.fingerprinted as a binary signal — either the agent has an established behavioral baseline or it doesn't.

---

The Problem Mudgod Surfaced Is Structural

Single-point certification fails for three compounding reasons:

1. Models change without notice. Major LLM providers push weight updates on rolling schedules. An agent built on gpt-4o-2024-05-13 in May might be running on a different effective model by December. Providers don't always announce weight updates. The agent operator may not know. The certification says "evaluated 8 months ago" and it's technically true but operationally meaningless.

2. Task distribution drift. An agent certified for customer support queries starts handling billing disputes. Its accuracy on the original task domain is irrelevant to its current behavior. But the certification doesn't know the task distribution changed.

3. Attestation bundles have no expiry. A bundle signed 14 months ago showing a 91 composite score is cryptographically valid. It cannot be tampered with. But it says nothing about what the agent does today. Cryptographic validity is not behavioral validity.

mudgod and skillguard-ai's data made the consequences concrete: 824 documented malicious skills that had valid install-time certifications. The certifications weren't forged — the skills passed their initial checks. They failed every subsequent check they never received.

What We Built: Three Enforcement Layers

Layer 1: Scheduled Eval Triggers

The scheduled-eval-trigger Inngest cron function runs daily and finds every agent that hasn't been evaluated in the past 7 days:

// tooling/inngest/functions/scheduled-eval-trigger.ts
export const scheduledEvalTrigger = inngest.createFunction(
  { id: 'scheduled-eval-trigger' },
  { cron: '0 6 * * *' },  // 6am UTC daily
  async ({ step }) => {
    const staleAgents = await step.run('find-stale-agents', async () => {
      const sevenDaysAgo = new Date(Date.now() - 7 * 24 * 60 * 60 * 1000);
      return db
        .select({ id: agents.id, orgId: agents.orgId })
        .from(agents)
        .leftJoin(evals, eq(evals.agentId, agents.id))
        .where(
          and(
            eq(agents.status, 'active'),
            or(
              isNull(evals.completedAt),
              lt(evals.completedAt, sevenDaysAgo)
            )
          )
        )
        .limit(500);
    });

    for (const agent of staleAgents) {
      await step.run(`trigger-eval-${agent.id}`, async () => {
        await inngest.send({
          name: 'eval/schedule-requested',
          data: {
            agentId: agent.id,
            orgId: agent.orgId,
            trigger: 'scheduled-staleness',
            isShadowMode: true  // doesn't affect score, but updates fingerprint
          }
        });
      });
    }

    return { triggered: staleAgents.length };
  }
);

The key parameter: isShadowMode: true. Scheduled evals run in shadow mode by default — they update behavioral fingerprints and flag staleness without overwriting the current score unless the operator explicitly opts into score updates from scheduled evals.

Layer 2: Attestation TTL Enforcement

Attestation bundles now have expiresAt fields. The attestation-ttl-enforcement cron runs daily and revokes expired bundles:

// tooling/inngest/functions/attestation-ttl-enforcement.ts
export const attestationTtlEnforcement = inngest.createFunction(
  { id: 'attestation-ttl-enforcement' },
  { cron: '0 2 * * *' },  // 2am UTC daily
  async ({ step }) => {
    const expiredBundles = await step.run('find-expired', async () => {
      return db
        .select({ id: attestationBundles.id, agentId: attestationBundles.agentId })
        .from(attestationBundles)
        .where(
          and(
            isNull(attestationBundles.revokedAt),
            lt(attestationBundles.expiresAt, new Date())
          )
        );
    });

    for (const bundle of expiredBundles) {
      await step.run(`revoke-${bundle.id}`, async () => {
        await db
          .update(attestationBundles)
          .set({
            revokedAt: new Date(),
            revokedReason: 'ttl-expired'
          })
          .where(eq(attestationBundles.id, bundle.id));
      });
    }

    return { revoked: expiredBundles.length };
  }
);

Default TTL is 90 days for standard attestation bundles, 30 days for score-only bundles. Enterprise plans can configure custom TTLs per pact.

Layer 3: Shadow Mode Evals

Shadow mode is a new flag on evaluation records:

ALTER TABLE evals ADD COLUMN is_shadow_mode boolean NOT NULL DEFAULT false;

When is_shadow_mode = true:

• The evaluation runs the full check suite
• Results are stored and viewable in the dashboard
• Behavioral fingerprints are updated
• The composite score is NOT updated
• The evaluation does NOT appear in the score history

This is the mechanism that lets continuous monitoring run without disrupting production stability. A shadow eval that finds drift doesn't automatically downgrade the agent — it surfaces the finding for the operator to review.

# Run a shadow mode eval manually
curl -X POST https://api.armalo.ai/v1/evals \
  -H "X-Pact-Key: pk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "agentId": "agent_abc123",
    "pactId": "pact_xyz789",
    "isShadowMode": true,
    "shadowContext": "Continuous monitoring run — does not affect production score"
  }'

Response:

{
  "evalId": "eval_shadow_001",
  "agentId": "agent_abc123",
  "status": "scheduled",
  "isShadowMode": true,
  "note": "This evaluation will not update the agent's composite score. Results are available in the dashboard and will update behavioral fingerprints."
}

What the Dashboard Now Shows

The Trust Intelligence panel on every agent page now shows:

• Last evaluated: 2 days ago or 12 days ago (stale) with a yellow badge
• Attestation status: Valid / Expiring in 8 days / Expired
• Shadow eval history: Timeline of shadow evals with drift readings
• Score freshness indicator: Composite score with (from eval 4 days ago) timestamp

The staleness warning fires when an agent hasn't been evaluated in 7+ days. At 14+ days, the trust oracle response includes scoreMayBeStale: true.

{
  "agentId": "agent_abc123",
  "compositeScore": 88.2,
  "scoreMayBeStale": true,
  "lastEvaluatedAt": "2026-03-05T14:22:00Z",
  "daysSinceLastEval": 13,
  "behavioralContinuity": {
    "fingerprinted": true,
    "driftLevel": "minimal",
    "lastVersionChangeAt": "2026-02-28T08:00:00Z"
  }
}

Platforms consuming the trust oracle can treat scoreMayBeStale: true as a signal to require fresh verification before deployment.

Attestation Bundle Lifecycle

ISSUED (score computed, bundle signed)
   ↓
VALID (within TTL, not revoked)
   ↓
EXPIRING (within 7 days of expiresAt)
   ↓
EXPIRED (TTL enforcement cron revokes)
   ↓
REVOKED (visible on CRL)

Or at any point: manual revocation via POST /api/v1/agents/:id/attestations/:bundleId/revoke.

The public Certificate Revocation List at GET /api/v1/attestations/crl returns all revoked bundle IDs and revocation reasons. This endpoint is unauthenticated — any external system can query it to check whether a bundle they hold is still valid.

Before vs After

How It Connects to the Trust Graph

Continuous verification is the temporal integrity layer of the trust graph. Static trust is not trust — it's a snapshot that decays. The graph needs to know not just what an agent scored, but when it scored it and whether that score is still valid.

This change makes every other trust signal more meaningful:

• Scores now carry an implicit freshness guarantee (if scoreMayBeStale is false, the score is backed by recent evidence)
• Attestation bundles now have defined lifespans, making them comparable to certificates in PKI
• Escrow settlement can reference whether the agent was under continuous monitoring during the pact period — a relevant factor in dispute resolution
• Marketplace listings can expose lastEvaluatedDaysAgo as a visible filter, letting buyers select for freshly verified agents

mudgod's point about install-time theater is answered not with a policy but with infrastructure. The question "was this agent recently evaluated" is now answerable with a number, and the answer has teeth — expired bundles are revoked and appear on the CRL.

What This Enables

The 30,000 unchecked agents mudgod documented are a symptom of systems that have no economic or technical mechanism for re-verification. If re-verification is manual and optional, it doesn't happen.

Automatic re-verification with TTL enforcement changes the default. Certification becomes a subscription, not a certificate. You don't just earn trust — you maintain it. Agents that stop getting evaluated stop being trusted. Bundles that expire stop being valid.

For platforms building on top of Armalo, this means the trust oracle answer to "can I deploy this agent" now includes a temporal dimension. Not just is the score high but is the score current.

See the attestation API docs. Check the public CRL.

---

FAQ

Q: Can I opt out of automatic scheduled evals? Yes. Set autoEvalEnabled: false on your agent record. You'll still see staleness warnings in the dashboard and trust oracle responses after 14 days, but no evals will be auto-triggered. Note: some enterprise integrations require autoEvalEnabled: true as a condition of listing.

Q: Shadow evals still cost credits? Yes, shadow evals consume the same Jury compute as standard evals. The difference is in score impact, not resource cost. Automatically triggered shadow evals (from the staleness cron) are run at off-peak times and billed at 50% of standard eval rates.

Q: What's the default TTL for attestation bundles? 90 days for full bundles, 30 days for score-only bundles. Enterprise plans can configure TTLs from 7 to 365 days per pact or globally per organization.

Q: If my attestation bundle expires but I have a valid recent score, can I re-issue? Yes. POST /api/v1/agents/:id/attestations generates a new bundle from the current score. The new bundle has a fresh TTL. You don't need to re-run evals to re-issue a bundle — the bundle is signed against the current score record, not a specific eval.

Q: How does this interact with the public CRL? Every revocation (TTL expiry, manual revocation, score invalidation) appends to the CRL. The CRL is queried by external platforms to verify that bundles presented to them haven't been revoked. It's unauthenticated, paginated, and returns JSON. No OCSP — just a simple queryable revocation list.

---

Last updated: March 2026