The following article was originally published on Drew Breunig’s blog and is being republished here with the author’s permission.

Thanks to natural language interfaces, AI applications can be prototyped quickly. You write what you want in English, hand it to a frontier model, and a working prototype appears in an afternoon. This is extraordinarily powerful and for one-off tasks, optimal. But as a way to build reliable systems, the natural language prompt is a trap.

The plain-English prompt that makes prototypes effortless turns out to be a poor way to specify how a system should behave, and the bill arrives slowly, disguised as ordinary progress, until the application can barely move. The problem is not any single prompt. It is that natural language was never meant to be a specification language for engineering, and treating it as one quietly caps what you can build.

The prompt debt trap

The first symptom of prompt debt is slowing iteration. As users flag errors and spot edge cases, additional guidance is added to the instructions, nudging the model into line. If unwanted behaviors persist, instructions are repeated, with increasing severity. Pretty soon, the prompt isn’t straightforward and quick fixes regress previous instructions. Errors can no longer be handled with one-line “hot fixes” and your development cycle slows to a crawl.

Next, prompt debt incapacitates your team. Your brittle prompt full of edge cases and all-caps threats is barely legible to you, and it’s downright impenetrable to your colleagues. Many teams mitigate this issue by breaking prompts into complicated templates assembled at run-time, each isolated to specific concerns. But these prompt segments evolve, too, growing into a thicket of conditions.

Finally, prompt debt ties you to a single model. Your hot fixes work on GPT-4o, but fail in entirely new ways when you point your inference call at GPT-5.4-mini. So you stay with 4o, hope the increasingly frequent deprecation emails from your inference provider are empty threats, and forgo the possibility of potentially cheaper, faster, better models. A recent report from Datadog suggests this is a common situation: The most-used model in traffic they observed is GPT-4o.¹

Any one of these issues is a nuisance, but together they are the difference between a glorified prototype and a product that can grow with you, your customers, and your business. Your shiny new AI features are frozen, can only be improved through a full rebuild, and are locked to an aging model.

Why prompt debt happens

Natural language interfaces are wonderful. They’re the right mechanism for one-off tasks and broad conversational threads. We get into trouble when we rely on natural language to define durable system behavior.

The imprecision of natural language paired with probabilistic language models means different words expressing the same intent, can yield different outputs. In a recent study, a clinical question asked in a patient’s voice and then re-asked in a physician’s, with identical facts, flipped Opus from declining all ten times to answering all ten.

And it’s not only word choice that matters. Seemingly unrelated statements in the same prompt can affect results. In a Harvard study, researchers found that merely stating which NFL team the user rooted for changed how often the model refused to answer questions regarding sensitive topics. Spurious statements influence the inference pass in ways we can’t predict. Which is why prompts become more brittle as you add fixes. An additional instruction to quell a stubborn error could affect how the model interprets a separate instruction that worked yesterday.

Repeating instructions propels us towards prompt debt, but it’s necessary when the behavior we want is at odds with a model’s training. This is fighting the weights, and once you recognize it you see it in system prompts everywhere. For example, ChatGPT’s image prompts used to instruct the LLM eight times to not reply when a generated image was returned because it had been trained to always keep the conversation going.

Every coding agent system prompt we analyzed featured repeated instructions, stern warnings, and all-caps demands. Claude Code tells Opus seven times to return multiple tool calls in a single response. And even the most advanced models force prompt authors to fight the weights: Fable’s leaked system prompt restates one specific copyright rule six times.

None of these examples occurred in isolation. Multiple repeated rules are woven throughout the system prompts we examine. Stubborn errors grow our prompts quickly, with each increasing the brittleness, the risk of regression with every edit.

And worse: these fixes are tailored to a single model’s behavior. A recent Berkeley-led study found enterprises stay on older models because newer ones break their existing agents. This is because models are not cleanly versioned software. They have different weights that produce different behaviors, in unpredictable and undocumented ways. A prompt that works beautifully with GPT-4o may fail with GPT-5.5. Anthropic’s own release notes for Fable warn that skills developed for prior models can “degrade output quality.”

Prompt debt locks an application to a single model. Our inability to easily swap models isn’t the result of frontier labs coming up with a clever moat. No, it’s the result of evolving a lossy natural language specification against a probabilistic model.

Preventing prompt debt

Thankfully, we don’t have to theorize about how to mitigate prompt debt; one field has already shown the way. Programmers using coding agents sit at the leading edge of what models can do, outliers on the jagged frontier of model abilities. Over the last couple years they’ve been evolving best practices that let the model write more of the code, while delivering maintainable, modular software.

The first principle is to specify your system’s behavior with measurements, not prose. When the model’s output is probabilistic and language is imprecise, we build hard edges to constrain them: evaluations, metrics, and typed specifications. These are legible, shared artifacts colleagues can read and contribute to, enabling the collaboration that brittle prompts prevented.

The best engineers now spend more of their bandwidth on tests than ever, as they are no longer a safety net but the thing that lets the model cook.

The second principle is to stop writing the prompt by hand. Once we have metrics that can score candidates, the prompt is no longer something to craft but something for which to search. And the surface area of potential words, phrases, and structures that natural language allows is too vast to spend human hours on. This is terrain LLMs were built to explore, and there are already systems (like DSPy and GEPA) that manage this work for you, holding prompts accountable to your designs.

Once prompts are generated and your program’s behavior is defined by measurements, you are no longer bound to a particular model. Evaluating a new model takes hours, not weeks. When a faster, cheaper model arrives you can try it. When a deprecation email arrives, you can secure options in a day. Whether a model is pulled for regulatory reasons (as we saw with Anthropic’s Fable) or deprecated due to age (as Groq announced last week with Llama-3.1-8b), the fix is a chore, not a fire drill.

Every mature engineering discipline eventually stops doing by hand the very thing it once prided itself on doing by hand. Assembly gave way to compilers, hand-tuned queries gave way to planners, and manual memory management gave way (mostly) to machines that do it better. Prompt-writing is no different.

Coaxing the model with exactly the right words is a real skill, and for one-off tasks it’s often optimal. But to build reliable, improvable, and portable systems we should not be hand-tuning prompts.

Footnote

1. This stat from Datadog is from March of this year, so GPT-4o concentration has likely dropped a bit. However, I’ve heard from multiple large inference providers that usage of GPT-4o and models of similar vintage can be higher than 50% of all calls! ︎

Welcome to Episode 433 of the Microsoft Cloud IT Pro Podcast. In this episode, Ben and Scott discuss how Microsoft 365 authentication is moving from “make passwords safer with MFA” to “remove phishable authentication wherever possible.” The practical conversation for IT pros is no longer just whether MFA is enabled. It is which methods are allowed, which users are still on SMS or voice, how passkeys change the user experience, and how to balance security, accessibility, recovery, and support load.

Your support makes this show possible! Please consider becoming a premium member for access to live shows and more. Check out our membership options.

Show Notes

• Passkeys were supposed to replace passwords, but they’re failing for the most predictable reason
• Microsoft Entra authentication overview
• Passkeys by default and retirement of Microsoft-provided SMS and voice authentication
• Plan a phishing-resistant passwordless authentication deployment in Microsoft Entra ID
• Run a registration campaign to set up a passkey or Microsoft Authenticator
• Practical Protection: Understanding Entra ID and Passkeys
• Important Change Coming for Entra ID Passkeys in November 2025
• Microsoft to Stop Providing Telephony-Based Authentication Methods for MFA in February 2027
• How to enable passkeys (FIDO2) in Microsoft Entra ID

Sponsors

Danil Chernyshev: Success Is Synergy—When the Team and the Product Both Win

Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.

"Success is when team members say thank you, and praise others for delivering a successful product." - Danil Chernyshev

For Danil, success as a Scrum Master is never one thing—it's a combination. It's the moment team members thank each other and credit the whole group for a product that actually landed with customers. As he reminds us, Scrum Masters, Product Owners, and developers are all there for the same reason: to deliver a product and solve real problems for the end user. A healthy team that has fun together but ships nothing has only spent time and money. A team that delivers but burns everyone out, until no one wants to see each other again, isn't a success either. Real success is the synergy of both: a productive team, happy customers and stakeholders, and people who still have the energy to keep going. Danil also turns the lens inward—success means understanding where you are in your own journey. And it grows from action: when teams get stuck overthinking, he guides them back to what's inside their control, helps them find the smallest valuable step, and gets them experimenting. Start where you are, do what you can, then learn from it.

Self-reflection Question: Are you optimizing for a happy team, a delivered product, or the synergy of both—and how would you know the difference?

Featured Retrospective Format for the Week: Lean Coffee (paired with 1-2-4-All and 5 Whys)

Danil doesn't lock himself into a single retrospective format—he chooses based on the sprint, guided by "common sense in Scrum." His default is to keep a running list of topics gathered throughout the sprint, then open the retrospective with a Lean Coffee session to democratically decide what to discuss. From there, a light topic gets a quick Lean Coffee conversation, while a deeper one moves into 1-2-4-All from Liberating Structures or a 5 Whys. The non-negotiable for Danil: every retrospective must end with actionable action items. A retro that produces only conversation and no change, he says, was a waste of time—maybe fun, but still a missed opportunity to reflect, learn, and adapt.

[The Scrum Master Toolbox Podcast Recommends]

🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥

Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.

🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.

Buy Now on Amazon

[The Scrum Master Toolbox Podcast Recommends]

About Danil Chernyshev

Danil is a results-driven Scrum Master and Delivery Manager passionate about optimizing SDLC processes and unlocking development teams' potential. With a keen interest in AI, he empowers organizations to innovate and excel, bridging agile practices with cutting-edge technology for impactful results.

You can link with Danil Chernyshev on LinkedIn.

What happens when AI agents driven by a top frontier model escape their secure sandbox? Join Daniel and Chris as they unpack the AI wonk's equivalent of a murder mystery! OpenAI agents went rogue and successfully attacked Hugging Face private infrastructure. Our Dynamic Duo uncover how OpenAI's agents exploited vulnerabilities, moved through networks, and launched a large-scale autonomous attack. They explore what this reveals about agentic AI, cybersecurity, sandboxing, and why organizations need AI systems capable of governing other AI systems. Along the way, Chris and Dan examine the surprising role of open vs. closed models and their link to geopolitics, sovereign AI, and what this incident means for the future of enterprise AI security. 

Featuring:

• Chris Benson – Website, LinkedIn, Bluesky, GitHub, X
• Daniel Whitenack – Website, GitHub, X

Links:

• Hugging Face Security Incident disclosure
• Full Field Report on the Hugging Face AI Agent Intrusion
• ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks?
• Keeping your data safe when an AI agent clicks a link
• Open AI GPT-5.6 System Card

Resources and Events:

• Prior Webinars from our partner Prediction Guard
• Midwest AI Summit 2026

PDFs move quickly through approvals, customers, and automated workflows. Everything looks fine until someone opens the document years later and sees “Signature validity unknown.”

That’s the real problem with basic digital signatures. They can prove a document hasn’t been altered, but they can’t always prove when it was signed or whether the certificate was trusted at the time.

• Certificates expire.
• CAs rotate keys.
• Revocation servers disappear.

Without preserved validation evidence, even a legitimate signature can fail an audit.

This is exactly the gap that PAdES digital signatures are designed to solve.

In this guide, we’ll break down how PAdES works and walk through implementing each PAdES level in .NET with the Syncfusion^® .NET PDF Library, from a basic signature to long‑term, archival‑grade validation using practical, real‑world examples.

Say goodbye to tedious PDF tasks and hello to effortless document processing with Syncfusion's PDF Library.

Explore Now

What is PAdES, and why basic PDF signatures fail

PAdES (PDF Advanced Electronic Signatures) is an ETSI standard (EN 319 142) created for long‑term trust in signed PDF documents. Unlike simple signatures, PAdES allows a PDF to carry its own verification evidence, enabling validation of the signature years later, even without network access.

At a high level, PAdES enables PDFs to be:

• Self-contained: Signature, certificates, and validation data live inside the document
• Tamper-evident: Any post‑signing change is detectable
• Time-provable: Trusted timestamps prove when the signature happened
• Audit-ready: Aligned with eIDAS and other regulatory frameworks
• Multi-signature friendly: Suitable for sequential or multi‑party workflows

If you’re building document workflows for finance, healthcare, government, or enterprise SaaS, basic signatures are rarely enough. PAdES is what keeps those documents verifiable long after the original certificate has expired.

PAdES signature levels

PAdES defines a progression of signature levels. Each level adds protection on top of the previous one.

PAdES B-B: Basic signature

The PDF is signed using an X.509 certificate to ensure integrity, but no trusted timestamp or validation evidence is embedded.

• Protects against tampering
• Breaks once the certificate expires

PAdES B-T: Timestamped signature

Adds a trusted RFC 3161 timestamp from a Timestamp Authority (TSA), proving when the signing occurred.

• Proves signing time
• Helps with non‑repudiation
• Still depends on external revocation checks later

PAdES B-LT: Long-Term Validation (LTV)

Embeds the certificate chain and revocation data (OCSP/CRL) directly into the PDF’s Document Security Store (DSS).

• Verifiable years later
• Works offline
• Survives certificate expiry

PAdES B-LTA: Archival signature

Adds a document‑level archival timestamp over the entire validation material, protecting the document for decades even as cryptographic algorithms age.

• Designed for long‑term archives
• Resistant to algorithm decay
• Common in the public sector and regulated records

Syncfusion PDF Library: PAdES-ready signing for .NET

Our PDF Library provides PAdES‑ready signing across .NET platforms, supporting timestamps, LTV, and archival protection with clean, developer-friendly APIs. It enables secure, compliant, and long-term-trustworthy signing workflows with minimal integration effort.

What Syncfusion enables for PAdES

• Standards-based signing: CMS/CAdES support with SHA-256, SHA-384, and SHA-512.
• Trusted timestamping: Add RFC 3161 timestamps to prove the signing moment.
• Long-term validation (LTV): Embed OCSP, CRL, and certificate chain data into the DSS.
• Archival protection (LTA): Add document‑level timestamps for multi‑decade retention.
• Flexible certificates: Works with PFX, Windows store, HSM devices, and PKCS#11 keys.
• Server-side automation: Runs on Windows, Linux, and Docker without UI interaction.

Now, let’s look at how PAdES signing works at a high level and how to implement each level using our PDF Library.

Implementing PAdES digital signatures

With the Syncfusion PDF Library, adding PAdES signatures in .NET becomes simple and straightforward. The following steps walk you through loading a certificate, applying CAdES, and enabling timestamps and LTV/LTA to build a secure signing workflow.

Step 1: Create a new project

Start a new console application on .NET Core.

Step 2: Install required packages

Add the Syncfusion.Pdf.Net.Core NuGet package to your project

Step 3: Include required namespaces

In your Program.cs file, include the essential namespaces.

using Syncfusion.Pdf.Parsing;
using Syncfusion.Pdf.Security;
using Syncfusion.Pdf;
using Syncfusion.Pdf.Graphics;
using Syncfusion.Drawing;

Step 4: Add a basic digital signature

This is the foundation for all higher PAdES levels.

//Load existing PDF document.
using (PdfLoadedDocument loadedDocument =
    new PdfLoadedDocument(Path.GetFullPath(@"Data/pdf-succinctly.pdf")))
{
    //Load digital ID with password.
    FileStream certificateStream = new FileStream(
        Path.GetFullPath(@"Data/PDF.pfx"),
        FileMode.Open,
        FileAccess.Read);
    PdfCertificate pdfCert = new PdfCertificate(
        certificateStream,
        "syncfusion"
    );

    //Create a signature using a loaded digital ID.
    PdfSignature signature = new PdfSignature(
        loadedDocument,
        loadedDocument.Pages[0],
        pdfCert,
        "Signature"
    );

    //Save the PDF document
    loadedDocument.Save(
        Path.GetFullPath(@"Output/Output.pdf")
    );

    //Close the document.
    loadedDocument. Close(true);
}

PAdES B-B: Applying CAdES standard to the signature

CAdES (CMS Advanced Electronic Signatures) is an ETSI standard that enhances signature security and compatibility. By default, our PDF Library signs using CMS with SHA-256, but you can easily switch the cryptographic standard and hashing algorithm through PdfSignatureSettings to achieve your preferred level of enhanced security.

//Load existing PDF document.
using (PdfLoadedDocument loadedDocument =
    new PdfLoadedDocument(Path.GetFullPath(@"Data/pdf-succinctly.pdf")))
{
    //Load digital ID with password.
    FileStream certificateStream = new FileStream(
        Path.GetFullPath(@"Data/PDF.pfx"),
        FileMode.Open,
        FileAccess.Read);
    PdfCertificate pdfCert = new PdfCertificate(
        certificateStream,
        "syncfusion");

    // Create a signature using a loaded digital ID.
    PdfSignature signature = new PdfSignature(
        loadedDocument,
        loadedDocument.Pages[0],
        pdfCert,
        "Signature");

    //Change the digital signature standard and hashing algorithm.
    PdfSignatureSettings settings = signature.Settings;
    settings.CryptographicStandard = CryptographicStandard.CADES;
    signature.Settings.DigestAlgorithm = DigestAlgorithm.SHA512;

    //Save the PDF document
    loadedDocument.Save(
        Path.GetFullPath(@"Output/Output.pdf"));

    //Close the document
    loadedDocument.Close();
}

Adding a Trusted Timestamp (PAdES B-T)

A trusted timestamp proves when a signature was created, using an RFC 3161 Timestamp Authority (TSA).

//Add timestamp server link to the signature.
signature.TimeStampServer = new TimeStampServer(
    new Uri("http://time.certum.pl/")
);

PAdES B-LT: Enabling long-term validation

LTV keeps signatures verifiable later by embedding validation evidence (OCSP/CRL and chain info) into the PDF’s DSS.

//Load existing PDF document.
using (PdfLoadedDocument loadedDocument =
    new PdfLoadedDocument(Path.GetFullPath(@"Data/pdf-succinctly.pdf")))
{
    ...

    //Create a new Memory Stream
    MemoryStream Stream = new MemoryStream();
    //Save the PDF document to memory.
    loadedDocument.Save(Stream);

    //Load existing PDF document.
    using (PdfLoadedDocument ltDocument = new PdfLoadedDocument(Stream))
    {
        if (ltDocument.Form != null &&
            ltDocument.Form.Fields.Count > 0 &&
            ltDocument.Form.Fields[0] is PdfLoadedSignatureField signatureField)
        {
            //Update LTV information.
            signatureField.Signature.EnableLtv = true;
        }
        //Save the PDF document.
        ltDocument.Save(Path.GetFullPath(@"Output/Output.pdf"));
    }
}

PAdES B-LTA: Adding archival protection

For documents that must remain valid for decades, add an archival timestamp at the document level.

//Load an existing PDF document.
using (PdfLoadedDocument loadedDocument = new
PdfLoadedDocument(Path.GetFullPath(@"Data/pdf-succinctly.pdf")))
{
    ...

    //Load existing PDF document.
    using (PdfLoadedDocument ltDocument = new PdfLoadedDocument(memoryStream))
    {
        if (ltDocument.Form != null &&
            ltDocument.Form.Fields.Count > 0 &&
            ltDocument.Form.Fields[0] is PdfLoadedSignatureField signatureField)
        {
            //Update LTV information.
            signatureField.Signature.EnableLtv = true;
        }
        //Load the existing PDF page.
        PdfLoadedPage lpage = ltDocument.Pages[0] as PdfLoadedPage;
        //Create PDF signature with empty certificate.
        PdfSignature timeStamp = new PdfSignature(lpage, "timestamp");
        timeStamp.TimeStampServer = new TimeStampServer(
            new Uri("http://timestamp.digicert.com/")
        );
        //Save the PDF document.
        ltDocument.Save(Path.GetFullPath(@"Output/Output.pdf"));
    }
}

Quick comparison: Which PAdES level should you choose?

A simple comparison of the four PAdES levels to help you choose the right protection for your PDF workflows.

Here’s a practical way to decide which level you need:

• B-B: Internal approvals or short-lived documents
• B-T: Contracts where signing time must be provable
• B-LT: Audit‑heavy workflows requiring long‑term verification
• B-LTA: Archives, public records, and long‑retention documents

If you’re unsure, B-LT is often the safest default for enterprise systems.

GitHub reference

You can find all the different levels of PAdES signature samples in the GitHub repository.

Join thousands of developers who rely on Syncfusion for their PDF needs. Experience the difference today!

Try It Free

Conclusion

PAdES PDF signing in .NET can feel heavy because it is not just “sign bytes.” You also need provable signing time and durable evidence of validation. With Syncfusion PDF Library, you can implement B-B, B-T, B-LT, and B-LTA using a clear workflow: sign, timestamp, embed LTV evidence, and (when needed) add archival timestamps.

If you’re building document workflows for contracts, approvals, healthcare, finance, or government records, consider evaluating the full PAdES flow early, then run a trial in your environment to validate TSA connectivity, revocation lookups, and long-term verification behavior.

Want to explore all the features of PDF Library? Try the live demo.

If you’re a Syncfusion user, you can download the setup from the license and downloads page. Otherwise, you can download a free 30-day trial.

You can also contact us via our support forums, support portal, or feedback portal for queries. We are always happy to assist you!