Zum Hauptinhalt springen
tsecurity.de LIVE
Echtzeit-Radar & Feeds
Alle RSS Feeds
👥 Community & Social
Windows Tipps & SecurityNighthawk M7 Pro im Test: Flexibler, aber teurer 5G-Router(21.09.2026 um 10:30 Uhr)
Sichere ProgrammierungNeue Gmail-Funktion: So sparst du jetzt Zeit bei Einmalcodes(21.09.2026 um 10:00 Uhr)
Sichere ProgrammierungYour GIF exporter is fine — the container is the problem(21.09.2026 um 10:01 Uhr)
Sichere ProgrammierungCSS, Motion, or GSAP? I Choose by Who Owns the Animation(21.09.2026 um 10:12 Uhr)
Windows Tipps & SecurityNighthawk M7 Pro im Test: Flexibler, aber teurer 5G-Router(21.09.2026 um 10:30 Uhr)
Sichere ProgrammierungNeue Gmail-Funktion: So sparst du jetzt Zeit bei Einmalcodes(21.09.2026 um 10:00 Uhr)
Sichere ProgrammierungYour GIF exporter is fine — the container is the problem(21.09.2026 um 10:01 Uhr)
Sichere ProgrammierungCSS, Motion, or GSAP? I Choose by Who Owns the Animation(21.09.2026 um 10:12 Uhr)
Intelligence View
⚡ tsecurity.de Intelligence

Your AI agent needs a governance layer, not just guardrails

Your AI agent needs a governance layer, not just guardrails Your AI agent approved a $2.4M loan disbursement at 2:47am. No human reviewed it. You find out because the customer called. You pull the logs there are none that matter. You…

0
↗ Quelle (dev.to)
Reagiere als Erste:r — dein Feedback zählt!




Your AI agent needs a governance layer, not just guardrails



Your AI agent approved a $2.4M loan disbursement at 2:47am. No human reviewed it. You find out because the customer called. You pull the logs there are none that matter. You check the prompt it looks fine. You check the output validator it passed. You have no idea what policy version ran, what signals the model saw, or whether anyone could tamper with the record between then and now. You are completely exposed.



This is not a hypothetical. If you're shipping agents that make decisions with real consequences approvals, disbursements, escalations, data access you've already built the system that will eventually put you in this position.









The problem with "guardrails"



The AI safety tooling ecosystem has converged on a pattern: wrap the model, validate the output, maybe add a confidence threshold. If the output looks wrong, reject it. This is guardrails. It is not governance.



Here's the distinction that matters:



Prompt engineering tells the model what to prefer. It has no enforcement at execution time, no version control that matters legally, and no proof it ran as written.



If/else output validation is application code. It changes with every deploy, has no audit trail beyond whatever you happen to log, and is trivially bypassed by a code change that nobody flagged.



LLM output validators (JSON schema checks, confidence thresholds, classifier-based filters) tell you whether the output looks acceptable. They cannot tell you which policy version ran, whether the same decision would be reached given the same inputs tomorrow, or whether the record has been modified since execution.



None of these produce a verifiable record. They produce logs. Logs are mutable. Logs are incomplete. Logs are not proof.



When your compliance team asks "show me that this specific loan was approved by this specific policy version with these specific inputs, and prove it hasn't been altered," logs cannot answer that question. A cryptographic attestation can.









What governance actually means



Four properties. If your decision system doesn't have all four, it's not governance:



Determinism given the same policy version and the same inputs, you always get the same output. No randomness, no model temperature, no hidden state. The decision is a pure function. Analogy: a court ruling that can be re-derived from the record.



Cryptographic attestation the decision, its inputs, and the policy version are hashed together and signed with a private key at execution time. Nobody can modify the record after the fact without the signature failing verification. Analogy: a notarized document where the notary's seal proves it hasn't been altered.



Replay protection each execution has a unique fingerprint derived from the policy ID, version, and canonical input hash. The same fingerprint cannot be submitted twice. Analogy: a check with a serial number once cashed, it can't be cashed again.



Independent verifiability any party holding the public key can verify the attestation without access to the live system, the database, or any runtime state. The proof is self-contained. Analogy: anyone can verify a PGP-signed message you don't need to call the author.



These four properties are what turn "we think the right policy ran" into "we can prove the right policy ran."









Show me the code



Here's a loan approval agent using @parmanasystems/core. The AI model produces a recommendation. Parmana Systems enforces whether the system is authorized to act on it.




import crypto from "crypto";
import {
executeFromSignals,
LocalSigner,
LocalVerifier,
MemoryReplayStore,
} from "@parmanasystems/core";

// Your Ed25519 keypair — use AWS KMS or similar in production
const { privateKey, publicKey } = crypto.generateKeyPairSync("ed25519", {
privateKeyEncoding: { type: "pkcs8", format: "pem" },
publicKeyEncoding: { type: "spki", format: "pem" },
});

const signer = new LocalSigner(privateKey);
const verifier = new LocalVerifier(publicKey);
const replayStore = new MemoryReplayStore();

// Signals come from your AI pipeline, your data layer, your risk engine
// The model recommended approval — now governance decides if it can execute
const attestation = await executeFromSignals(
{
policyId: "loan-approval",
policyVersion: "2.1.0",
signals: {
applicant_id: "usr_8f3k2p",
requested_usd: 240000,
credit_score: 712,
dti_ratio: 0.31,
employment_months: 26,
model_recommendation: "approve", // from your LLM
},
},
signer,
verifier,
replayStore
);

console.log(attestation.execution_state); // "completed"
console.log(attestation.decision.action); // "approve"
console.log(attestation.signature);
// "mK3nQs8rXpLw2YbD9eHtNcAoGiUjZlV0TfRkMyPh1CxBs6WqJ5IuEdOgPm4..."
// ↑ Ed25519 over canonical attestation JSON — 64 bytes, base64-encoded






The model_recommendation is just another signal. The governance layer decides whether the conditions for execution are met — the model doesn't get a vote in what the policy says. If credit_score drops below the policy threshold, you get execution_state: "blocked" regardless of what the model recommended.









What you actually get



Every call to executeFromSignals returns an ExecutionAttestation. Here's what each field proves:




{
executionId: "a3f2b1c4d8e7f96a...", // SHA-256 of policy + version + canonical signals
policyId: "loan-approval",
policyVersion: "2.1.0", // exact version — not "latest"
signalsHash: "8b3f9c2a...", // SHA-256 of canonical input signals
decision: {
action: "approve",
requires_override: false,
reason: "all thresholds met"
},
execution_state: "completed", // "completed" | "blocked" | "pending_override"
runtimeHash: "7d4e1f8a...", // hash of the runtime binary state at execution
runtimeVersion: "1.65.0",
signature: "mK3nQs8rXp..." // Ed25519 over all of the above
}






The signature is what makes this governance and not just logging. It is computed over a canonical JSON serialization of the entire attestation — deterministic key ordering, no whitespace variation. Any modification to any field after signing causes verification to fail.



Your compliance team can take this record offline no database, no production access and verify it:




import { verifyAttestation, LocalVerifier } from "@parmanasystems/core";

const verifier = new LocalVerifier(publicKey); // public key only — no secrets
const valid = verifyAttestation(attestation, verifier);
// true — or throws with the specific field that failed






They get a binary answer: this record is authentic and unmodified, or it isn't. No trust in your logging infrastructure required. No access to your production database. No reliance on your word.



This is the difference between "here are our logs" and "here is cryptographic proof."









Who should care about this



Fintech engineers shipping credit decisioning, payment approval, or trading workflows any jurisdiction that requires you to prove a specific policy version governed a specific transaction. MiFID II, SOC 2, PCI, Basel III all have audit requirements that logs don't fully satisfy. A signed attestation does.



AI platform teams building LLM agents with tool-use, autonomous pipelines, or multi-step decision chains. The moment your agent can trigger an action with real-world consequences — send money, modify records, escalate a decision — you need a layer that proves what authorized the action. "The model decided" is not an audit trail.



Anyone building autonomous systems that touch money, data, or decisions where a future regulator, auditor, customer, or legal team might ask: "prove that the right policy ran, with the right inputs, and that nobody changed the record." If you can't answer that question today, you will eventually be asked it at the worst possible time.



The pattern is always the same: something goes wrong, someone asks for proof, and you discover that your logging architecture was designed to help you debug, not to prove.









Try it



Parmana Systems is open source under Apache 2.0.




npm install @parmanasystems/core








The quickstart gets you to a signed attestation in under five minutes. The loan approval policy ships as a working example. If you're already running an agent in production, the integration surface is a single function call around your existing decision logic.



Governance isn't what you add after something goes wrong. It's what lets you prove nothing went wrong.

Ähnliche Beiträge
🔍 Verwandte News

Auch interessante Nachrichten Your AI agent needs a governance layer, not just guardrails

Thematisch verwandte Begriffe: Your, agent, needs, governance · 6 Treffer

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Zum Aktualisieren ziehen
ZERO-DAY CVE-2026-94030 | A security vulnerability has been detected in SerenityOS up to 3d83e4509…
Advisory →
TTS Reader • tsecurity.de Voice
tsecurity.de Icon
tsecurity.de App
Offline-Lesen, Eilmeldungen & 0ms Ladezeit

Installiere tsecurity.de direkt auf deinen Home-Bildschirm für das ultimative Vollbild-Magazinerlebnis ohne Browser-Leisten.

Nächster Beitrag
Themen-Radar & Intelligence Matrix
Echtzeit-Taxonomie nach Angriffsvektoren & Plattformen

tsecurity.de Live Threat Radar

🔴 LIVE RADAR
MONITORING
AKTIV
CVE-DATENBANK
LIVE
🔍
Community Radar & Live Chat
Sentinel Bot online • Live-Stream
Dein Cluster: Security Explorer
Match:
lädt…
Verbindung zum Community-Stream wird aufgebaut...
Bearbeitungsmodus — Senden überschreibt deine Nachricht
Community-Puls — was gerade passiert
lädt…
Aktivitäten deiner Analysten
lädt…
Neues Thema oder Eilmeldung einreichen

Reiche interessante Links, Zero-Days oder Debatten ein. Die Community entscheidet per Upvote über die Veröffentlichung.

Heiß diskutierte Einreichungen
🔖 Gespeicherte Artikel
📂 Keine gespeicherten Artikel vorhanden.
Zurück Ziehen Vor
Links: vorheriger Artikel Rechts: nächster Artikel unten: schließen
News NIS-2 Frühwarnung Tier-1 Intel ⏱️ 3 Min vor 10 Min
Artikeldaten werden geladen...

Zurück: vorheriger Vor: nächster
↗ Original-Quelle
Social Reaktionen Deine Reaktion zählt
Einstufung & Relevanz-Poll 0 Stimmen
In sozialen Netzwerken teilen 1-Klick