Coder Legion - Recent posts tagged token

Your AI Coding Agent Is Paying to Read Code It Doesn't Need

Tue, 22 Sep 2026 09:32:52 +0000

Your AI Coding Agent Is Paying to Read Code It Doesn't Need

AI coding agents have become surprisingly good at changing code.

But we are still giving them files as if they were human developers sitting in front of an editor.

And that is expensive.

Imagine your agent needs to rename one identifier inside a 2,000-line file.

The actual change might be:

oldName → newName

A few tokens of useful information.

Yet the typical agent workflow looks something like this:

read 2,000 lines
↓
reason about one relevant line
↓
edit the file
↓
read the file or diff again
↓
continue carrying much of that context

The agent may consume tens of thousands of tokens to perform an operation whose semantic payload is only a handful of tokens.

That feels backwards.

What if the agent never opened the file?

This is the idea behind RAP — Runtime Apply Patch.

Instead of asking an agent to read a file, locate something, rewrite it, and verify the result, RAP lets the agent address the code directly by its content.

For example:

rap s app.go 'oldName' 'newName'

RAP answers:

updated app.go (lines 1697 -> 1699, bytes +133, replacements 1)

That's it.

The agent did not need to load 2,000 lines into its context.

It already knew what it wanted to change.

RAP simply found it and performed the operation.

The principle can be summarized in three words:

Lines, not files.

Files are a human abstraction

Files are extremely useful for humans.

We open app.go, scroll around, understand the surrounding code, make a change, save it, and inspect the result.

But an AI agent does not necessarily need to reproduce that workflow.

If an agent already knows:

OLD = "oldName"
NEW = "newName"

why should it pay the context cost of reading another 1,999 lines?

The information required to describe the mutation and the information required to store the program are two very different things.

RAP tries to keep them separate.

The filesystem stores the program.

The model describes the mutation.

RAP connects the two.

Content becomes the address

Traditional editing often addresses code through coordinates:

file → line → column

But coordinates are fragile.

Insert ten lines above the target and the address changes.

RAP instead addresses code by content:

file → known text → replacement

The interesting consequence is that the agent often already possesses the address.

Maybe the target came from a previous grep.

Maybe it appeared in an error message.

Maybe the user provided it.

Maybe the agent wrote that code itself thirty seconds ago.

There is no reason to reload the entire file merely to rediscover information already present in the agent's context.

What if the target is ambiguous?

Then RAP stops.

$ rap s app.go 'count' 'total'
rap: OLD matched 3 times; use -all or a more specific OLD

Nothing gets written.

This property matters more than it might initially appear.

Shell tools can be extremely efficient for agents, but commands such as sed can also silently perform a perfectly valid operation on the wrong piece of text.

For an autonomous agent, failure is often cheaper than confidence.

A failed command may cost a dozen tokens.

A wrong edit can contaminate several subsequent reasoning steps before the mistake is discovered.

RAP therefore prefers an explicit refusal over an ambiguous mutation.

But sometimes the agent really does need context

Of course.

The argument is not that agents should never read source code.

The argument is that reading an entire file should not be the default unit of interaction.

RAP provides smaller operations for the questions agents actually ask.

Want to know whether a target is unique?

rap m FILE 'text'

Result:

matches: 1

Want to inspect only the affected area?

rap preview -n FILE 40 60 -- s OLD NEW

The agent receives a small window instead of the whole building.

Need to pass ugly text containing quotes, JSON, shell characters, or newlines?

rap q -token @file

RAP turns it into a safe token representation.

And after an edit, the command itself returns a receipt describing what happened.

No automatic full-file reread is necessary just to ask:

Did it work?

The token economics are surprisingly large

Consider a 2,000-line source file representing roughly 25,000 tokens.

A conventional agent might:

read file        ~25,000 tokens
modify
inspect result   ~25,000 tokens

Potentially around 50,000 tokens of context traffic around an edit that may involve only one line.

With RAP, the interaction can look more like:

rap s FILE OLD NEW

Perhaps ~40 input tokens and ~20 output tokens.

Obviously, real workloads vary. Agents sometimes genuinely need broader context, and not every edit can be expressed as a simple substitution.

But that is precisely the point.

Pay for context when reasoning requires context.

Do not pay for it merely because the code happens to live inside a large file.

This becomes more important as agents become more autonomous

Token efficiency is usually discussed as a model problem:

smaller prompts, better compression, larger context windows, cheaper inference.

But part of the problem may actually live outside the model.

Our tools still assume that an intelligent actor interacts with software primarily by opening documents.

Coding agents give us an opportunity to reconsider that assumption.

An agent does not necessarily need an editor.

It needs precise operations over a codebase, small observations about their consequences, and predictable failure modes.

That suggests a different interface between models and source code:

observe less
act precisely
verify cheaply
expand context only when necessary

RAP is a small experiment in that direction.

It does not try to make the model smarter.

It tries to make the model need fewer tokens to do the work it already knows how to do.

Lines, not files

The core idea behind RAP is intentionally simple:

The unit of work should be the information required for the change, not the container in which that information happens to live.

Sometimes that means a file.

Sometimes it means fifty lines.

Sometimes it means five.

And sometimes it means:

oldName → newName

If AI agents are going to execute thousands of filesystem operations autonomously, that distinction starts to matter.

A lot.

RAP is open source and available on GitHub.

Try giving your coding agent RAP and watch how often it can edit code without ever asking to see the whole file.

AI Fundamentals - Part 1: From Prompt to Response

Sun, 05 Jul 2026 05:09:30 +0000

AI is becoming a regular part of software development. Whether you're building chatbots, code assistants, search experiences, or internal tools, you'll come across terms like tokens, context window, attention, and temperature. While you don't need to understand the underlying mathematics to build AI-powered applications, understanding these fundamentals will help you make better design decisions, debug unexpected behavior, and discuss AI topics with confidence. In this series, we'll build that foundation one concept at a time.

Running Example

Throughout this series, we'll use a single application to explain every concept: an AI-powered Travel Planner.

Imagine a user enters the following prompt:

I'm visiting Japan for 7 days in October. Create an itinerary with sightseeing, local food, and a day trip to Mount Fuji.

It looks simple, but a surprising amount happens before the model generates the first word of its response. Here is the high-level journey:

User Prompt
      │
      ▼
 Tokenization
      │
      ▼
 Context Window
      │
      ▼
 Transformer
      │
      ▼
   Attention
      │
      ▼
Next-token Prediction
      │
      ▼
 Response

Let's start from the very beginning.

What Is an LLM?

An LLM (Large Language Model) is a machine learning model trained on enormous amounts of text to recognize patterns in language. Despite the impressive conversations they can have, LLMs aren't databases or search engines-they don't look up answers when you ask a question. Instead, they generate text by predicting what should come next based on everything they've seen so far. That single idea is the foundation for understanding modern AI.

Mental Model

An LLM is a very sophisticated next-word predictor. Technically, it predicts the next token, not the next word-but we'll get to that shortly.

💡 Developer's Takeaway

When your AI application responds, it is dynamically generating new text, not retrieving a predefined answer.

Prompt: Where Every Conversation Begins

Everything starts with a prompt, which is simply the input you provide to the model. For our travel planner, the prompt is:

I'm visiting Japan for 7 days in October. Create an itinerary with sightseeing, local food, and a day trip to Mount Fuji.

As developers, we usually think of this prompt as a string. However, the model doesn't process strings directly. Before it can do anything, it must first convert the text into something it understands: tokens.

Tokens: The Language an LLM Understands

Humans read words and sentences; LLMs read tokens. A token is a small piece of text. Depending on the tokenizer, it could be a complete word, part of a word, punctuation, a number, a symbol, or even a single character.

For example, our prompt might be broken into pieces like this:

I'm | visiting | Japan | for | 7 | days | in | October | ...

Or, depending on the model:

I | 'm | visit | ing | Japan | ...

The exact split varies between models, but the important takeaway is that models never see your original sentence; they only see tokens. This is why API pricing, context limits, and usage are almost always measured in tokens rather than words.

💡 Developer's Takeaway

If a provider says a model supports 128K tokens, that does not mean 128,000 words. Because tokens are typically smaller than words (averaging ~4 characters or 0.75 words per token in English), the actual word limit is lower.

Tokenization: Breaking Text into Tokens

The process of converting text into tokens is called tokenization. You can think of it as translating human language into the model's native numeric representation.

User Prompt ("I'm visiting Japan...") ──► Tokenizer ──► [5012, 382, 9182, 71, ...]

Internally, models work with numbers, not strings. Each token maps to a numeric identifier, which is what the model actually processes. Fortunately, tokenization happens automatically under the hood. As developers, we rarely need to perform it ourselves, but understanding that it exists helps explain many quirks of AI behavior.

💡 Developer's Takeaway

Tokenization is one reason two models can behave differently even when given the exact same prompt, as they might break down and interpret the text differently.

Context Window: The Model's Working Memory

Once the prompt is tokenized, those tokens are placed inside the model's context window. The context window is the total amount of information the model can consider while generating its response-essentially its active working memory for the current conversation.

For our travel planner, the context window might include:

The user's current request
Previous messages in the chat history
System instructions
Uploaded documents or external data

Everything inside the context window is available to the model; everything outside it effectively does not exist. This explains why long conversations sometimes cause the AI to forget details you mentioned earlier-those earlier tokens have simply been pushed out of the context window to make room for new ones.

💡 Developer's Takeaway

Many "memory" issues are actually context window limitations. Managing context efficiently-pruning old history or summarizing previous turns-is one of the most important aspects of building AI applications.

Transformer Architecture: The Engine Behind Modern LLMs

You've probably heard that modern language models are based on the Transformer architecture. At a beginner level, you don't need to understand the mathematics behind it. Instead, remember this: a Transformer is designed to process all tokens in a prompt in parallel, rather than reading them sequentially one-by-one (as older recurrent architectures like RNNs or LSTMs did).

This parallel processing allows the model to analyze the relationships between all parts of the prompt simultaneously and handle significantly larger context windows. It is the primary reason modern AI models are trained on massive datasets and feel dramatically more capable. One of the core mechanisms that enables this is Attention.

Attention: Focusing on What Matters

Imagine the model is generating the next part of our itinerary. Which parts of the prompt matter the most?

I'm visiting Japan for 7 days in October. Create an itinerary with sightseeing, local food, and a day trip to Mount Fuji.

Clearly, tokens like Japan, 7 days, and Mount Fuji are far more important than helper words like I'm, for, or in. The Attention mechanism helps the model mathematically calculate which tokens are most relevant to focus on while generating the next token.

It is similar to how a human reads: your eyes naturally focus on the core information rather than reading every word with equal weight. Without attention, generated responses would quickly lose coherence and drift away from the user's instructions.

💡 Developer's Takeaway

The clearer, more structured, and more focused your prompt is, the easier it is for the model's attention mechanism to isolate the key instructions and generate a relevant response.

Next-token Prediction: Generating One Token at a Time

Now the model is ready to generate its response. Contrary to how it looks on screen, the model does not generate an entire sentence or paragraph at once; it predicts one token at a time in a loop:

Prompt ──► Model predicts: "Day" ──► Context updated ──► Model predicts: "1" ──► ...

After generating a token, that token is appended to the context window, and the model runs again to predict the next token based on this updated history. This process repeats hundreds or thousands of times until the model generates a special "stop" token (indicating the end of the text) or reaches a length limit.

💡 Developer's Takeaway

Because responses are built incrementally one token at a time, the model is not "planning" the entire paragraph in advance. It only calculates the next most likely token based on what has already been written.

Parameters: What Do 7B and 70B Mean?

If you explore open-weight models, you will see numbers like 7B, 8B, or 70B. The B stands for billion parameters. Parameters are the internal values (weights) that the model learned and adjusted during its training phase. You can think of them as the neural connections that store the model's knowledge and language patterns.

In general, larger parameter counts mean:

The model knows more facts and language nuances.
The model has stronger reasoning capabilities.
The model requires significantly more memory (VRAM) and compute power to run.

However, parameter count isn't everything. A modern, well-trained 8B model can easily outperform an older, poorly trained 70B model. Model architecture, training data quality, and optimization techniques play a massive role.

💡 Developer's Takeaway

Don't choose a model solely based on parameter count. Evaluate smaller models first; they are faster and cheaper, and are often more than capable for specific tasks.

Temperature: Controlling Creativity

Suppose our travel planner receives the exact same prompt twice. Should it generate the exact same itinerary every time? Sometimes yes (for deterministic tasks like coding), and sometimes no (for creative tasks like brainstorming). This variation is controlled by temperature.

Temperature changes the probability distribution of the next token:

Low temperature (e.g., 0.1 - 0.3): The model becomes highly predictable, consistently choosing the most probable tokens. This is ideal for structured outputs (like JSON), code generation, and factual QA.
High temperature (e.g., 0.7 - 1.0): The model selects slightly less probable tokens, introducing randomness and variety. This is ideal for brainstorming, storytelling, and creative writing.

💡 Developer's Takeaway

Temperature does not make a model smarter or dumber; it simply controls how "adventurous" the token selection is. Always set temperature to 0 or near 0 when you need reliable, repeatable, or structured outputs.

Bringing It All Together

Let's review what happens when our user submits their prompt:

Tokenization: The text is split into numeric tokens.
Context Window: The tokens enter the model's active working memory.
Transformer & Attention: The model processes the tokens in parallel, identifying which parts are most important.
Next-Token Prediction: The model loops, predicting and appending one token at a time.
Temperature: The temperature setting influences how predictable or creative each token choice is.

Every modern AI assistant, chatbot, or code tool follows this exact core sequence.

Recap

In this article, we covered the journey from prompt to response, detailing:

LLMs as next-token predictors.
Tokenization and the context window.
The parallel processing of Transformers and the focus of Attention.
Parameters and Temperature control.

In Part 2, we'll explore why models can confidently generate incorrect answers, introducing pretraining, knowledge cutoffs, hallucinations, and how grounding and prompt engineering help resolve them.

David Chaum’s ghost in the machine: A warning from 1990.

Thu, 02 Jul 2026 06:39:57 +0000

David Chaum’s Ghost in the Machine: A 1990 Warning for Tomorrow’s Architects

Introduction

In the annals of cryptography and digital currency, David Chaum’s DigiCash stands as a monumental, if ultimately commercially unsuccessful, achievement. Conceived in the late 1980s and implemented in the 1990s, DigiCash was a pioneering force in truly anonymous, untraceable digital cash, built upon Chaum’s groundbreaking work on blind signatures. It promised financial privacy decades before Bitcoin or Ethereum entered the public consciousness. Recent academic archaeology, however, has unearthed a fascinating and somewhat chilling detail from the original DigiCash e-cash protocol’s server implementation: a subtle, nearly imperceptible timing oracle. This discovery isn’t just a historical footnote; it’s a profound warning from the past, demonstrating that even the most brilliant and privacy-focused designs can harbor systemic vulnerabilities that only manifest through meticulous analysis.

Code Layout/Walkthrough: Unmasking the Subtle Timing Oracle

While access to the full, original 1990s DigiCash source code remains a rare privilege, we can conceptually explore how such a timing oracle might have manifested within a simplified server-side blind signature processing flow. The core principle of blind signatures allows a user to “blind” a digital token (like a serial number), have a bank sign it without knowing its true value, and then “unblind” it, proving the bank’s signature without revealing the original token to the bank. The newly discovered oracle suggests a flaw in the server’s processing of these blinded requests.

Imagine a simplified server function responsible for handling a client’s request to “blindly withdraw” a digital coin:

# Conceptual representation of a DigiCash server-side processing function
def process_blinded_withdrawal_request(blinded_token_request: dict) -> dict:
    start_time = time.perf_counter() # For a hypothetical attacker's measurement

    # 1. Initial format validation (quick check)
    if not is_valid_json_format(blinded_token_request):
        time.sleep(0.001) # Simulate minimal processing for invalid format
        return {"status": "error", "message": "Invalid request format"}

    # 2. Extract potential token identifier (even if blinded)
    #    This step might involve cryptographic parsing that varies in time
    #    based on the token's structure or 'completeness'.
    try:
        derived_token_id = extract_derived_id(blinded_token_request['blinded_data'])
    except Exception:
        time.sleep(0.005) # Slightly longer for parsing errors
        return {"status": "error", "message": "Malformed blinded data"}

    # 3. Critical database lookups and state checks
    #    THIS IS WHERE A TIMING ORACLE COULD LIE.
    #    Imagine these lookups have different execution paths based on results.

    # Path A: Token is already known/spent (e.g., double-spend attempt)
    if database.token_exists_and_is_spent(derived_token_id):
        # This lookup might be very fast if it's a simple indexed check.
        # It's a "known bad" state.
        time.sleep(0.010) # Example: Database read for existing spent token
        return {"status": "error", "message": "Token already spent"}

    # Path B: Token is completely new and valid (requires more processing)
    if not database.token_exists_in_pending_pool(derived_token_id):
        # This path might involve deeper validation, generation of a new entry,
        # or more complex cryptographic operations before signing.
        # This is a "new good" state.
        time.sleep(0.050) # Example: More complex DB operations + cryptographic prep
        signed_token = server_sign_blinded_data(blinded_token_request['blinded_data'])
        database.add_to_pending_pool(derived_token_id, signed_token)
        return {"status": "success", "signed_token": signed_token}

    # Path C: Token is in a 'pending' state or has some other nuanced validity (DigiCash nuance)
    else: # Maybe a token that was partially processed or is from a specific batch
        # This path might have its own unique timing signature, different from A or B.
        time.sleep(0.030) # Example: A different kind of database lookup or logic
        return {"status": "error", "message": "Token in indeterminate state"}

    # The actual server response time (measured by client) would be end_time - start_time

The “ghost in the machine” here is the subtle, varying execution time of these different internal processing paths (represented by time.sleep() values). A malicious issuer, repeatedly sending different types of requests – some completely invalid, some partially malformed, some truly new, and some representing known double-spend attempts – could precisely measure the response times.

A very fast error response might indicate a trivial format error.
A slightly longer error response might indicate a parsing issue.
A medium-length error response might indicate the token was already recognized as “spent” (Path A).
A distinctly longer success response, or even a different kind of error response, might indicate a token that passed deeper validity checks or was being processed for signing (Path B or C).

By aggregating these timing differences, the issuer, despite the blinding, could potentially infer something about the nature or validity of the client’s original, truly anonymous request. This inference could, under specific circumstances, create linkages between transactions or de-anonymize certain user behaviors, chipping away at the very core promise of untraceability.

Conclusion

The discovery of a timing oracle in Chaum’s original DigiCash protocol is a powerful historical lesson for modern system architects. It underscores that even the most innovative and theoretically sound cryptographic protocols can harbor insidious vulnerabilities in their implementations. Such flaws are not always brute-force exploits but can be subtle, systemic, and rooted in the nuanced execution paths of seemingly innocuous code. This “ghost” from 1990 reminds us of the perpetual arms race in security: vigilance must extend beyond cryptographic primitives to every line of code, every database query, and every conditional branch. For anyone building the digital future, whether in blockchain, privacy-preserving AI, or secure distributed systems, DigiCash’s subtle flaw is a living textbook – a stark reminder that robust security demands an obsession with detail, relentless scrutiny, and an understanding that history’s lessons are often the most valuable blueprints for tomorrow.

How to Secure Nomad?

Fri, 01 May 2026 03:45:38 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

Nomad is a flexible workload orchestrator that enables an organization to easily deploy and manage any containerized or legacy application using a single, unified workflow.

Nomad can run a diverse workload of Docker, non-containerized, microservice, and batch applications.

With powerful features, it becomes very important to secure the Nomad cluster.

If anyone gets access to the cluster, it can lead to a big security risk.

In this article I will explain how to secure the Nomad cluster.

Enable ACL in Nomad

ACL is a feature in Nomad that allows you to control access to the cluster.

It is a way to implement the principle of least privilege, which means that users should only have access to the resources that they need to do their job.

To enable ACL in Nomad, you need to add the following lines to your Nomad server configuration file:

/etc/nomad.d/nomad.hcl

acl {
  enabled = true
}

Once it is enabled, you need to restart the Nomad server to apply the changes.

sudo systemctl restart nomad

Generate Security Token for Nomad

Once ACL is enabled, you need to generate a security token for Nomad.

You need to bootstrap the ACL system to generate the initial security token.

nomad acl bootstrap

It will return something like this

Accessor ID  = <ACCESSOR_ID>
Secret ID    = <SECRET_ID>
Name         = Bootstrap Token
Type         = management
Global       = true
Create Time  = <timestamp>
Expiry Time  = <none>
Create Index = <create_index>
Modify Index = <modify_index>
Policies     = n/a
Roles        = n/a

Copy and to a secure location. You will need this token to access the Nomad UI and API.

Once this is done if we try to access the Nomad UI or API without the token, it will return 403 Forbidden.

Which means ACL is enabled and working.

Create Policy for Users

As it is recommended not to use bootstrap token directly, we should create policies for users based on their roles.

Based on requirements you can create policies for users.

For example, let's create a policy for a user who can only read the jobs and node information.

Readonly access policy for a user.

namespace "default" {
  policy       = "read"
  capabilities = ["list-jobs", "read-job"]
}

agent {
  policy = "read"
}

operator {
  policy = "read"
}

quota {
  policy = "read"
}

node {
  policy = "read"
}

host_volume "*" {
  policy = "read"
}

This will make sure only read access for the users. This may be given to monitoring tools to monitor the cluster.

Create this file in ./nomad/policies/readonly.hcl

Once done create a token for this policy.

nomad acl policy apply -description "Readonly policy" readonly ./nomad/policies/readonly.hcl
Successfully wrote "readonly" ACL policy!

Create Keys for Selected Policy

nomad acl token create -name="Read Only Token" -policy="readonly"

This will return

Accessor ID  = <ACCESSOR_ID>
Secret ID    = <SECRET_ID>
Name         = Read Only Token
Type         = client
Global       = false
Create Time  = <timestamp>
Expiry Time  = <none>
Create Index = <create_index>
Modify Index = <modify_index>
Policies     = [readonly]

Roles
<none>

Now with this token we can access the Nomad UI and API with read only access.

Conclusion

Nomad is very powerful tool for orchestrating containers and other workloads.
But if we leave it unsecured it can be a security risk.
It is very important to secure the Nomad cluster.

So, I hope you understood how to secure the Nomad cluster.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

Are you paying attention to your token use?

Wed, 08 Apr 2026 18:22:26 +0000

Can I get some folks in the comments talking about how closely they monitor their token usage?

Or if you don't, do you work at a company that provides you unlimited tokens? To specific tools?

I'm curious to see where people fall on this spectrum.

Authentication Tokens: Your Digital VIP Pass

Wed, 24 Sep 2025 13:05:12 +0000

In today's connected world, we all want to access our favorite apps and websites without re-entering our password every two seconds. That's where authentication tokens, or "auth tokens," come in. Think of them like a digital VIP pass. When you log in with your username and password, the server checks your credentials and, if everything's good, hands you a special token. Instead of sending your password with every request, your app sends this token. The server then uses the token to confirm you're still you, and you can access all the cool stuff you're supposed to.

How It Works: A Simple Flow

The basic process is pretty straightforward:

Login: You enter your username and password on an application's login screen.
Verification: The application sends your credentials to its server for verification.
Token Generation: If your credentials are correct, the server generates a unique auth token.
Token Received: The server sends this token back to your application, which stores it, usually in a cookie or local storage.
Access: From now on, whenever you need to access a protected resource, like your profile page or your shopping cart, the application includes the token in the request header.
Token Validation: The server receives the request, validates the token, and grants access if it's valid.

This system is great for scalability because the server doesn't need to remember who is logged in. This makes the server stateless, which is a huge plus for performance and building microservice architectures.

Types of Tokens You'll Encounter

There are a few different types of tokens, each with its own pros and cons.

1. JSON Web Tokens (JWTs)

A JWT (pronounced "jot") is a popular type of token that's self-contained. This means all the necessary user information is right inside the token itself. A JWT is made up of three parts, separated by periods:

Header: Describes the token type and the signing algorithm.
Payload: Contains "claims," which are statements about the user and the token. This is where you'd find user ID, roles, and the token's expiration date.
Signature: A unique signature created using a secret key. This is what the server uses to verify that the token hasn't been tampered with.

Because a JWT contains everything the server needs to know, the server doesn't have to perform a database lookup for every request. This makes them really fast and efficient.

Here's a quick Python example using the PyJWT library to create a JWT:

import jwt
import datetime

payload_data = {
    'sub': '1234567890',
    'name': 'John Doe',
    'iat': datetime.datetime.now(datetime.timezone.utc),
    'exp': datetime.datetime.now(datetime.timezone.utc) + datetime.timedelta(minutes=30)
}

secret_key = 'your_super_secret_key' # In a real app, use an environment variable!

token = jwt.encode(payload_data, secret_key, algorithm='HS256')

print(token)

You can then decode and verify this token on the server side to get the payload data.

2. Opaque Tokens

Unlike JWTs, opaque tokens are just random strings of characters. The client can't read anything from them. They are essentially a reference to a record stored in the server's database. When a server receives an opaque token, it has to go to the database to look up the token and retrieve the associated user data and permissions.

Pros & Cons:

JWTs: Fast, scalable, and don't require database lookups. The downside is that once issued, they can't be easily revoked before they expire.
Opaque Tokens: More secure since no information is exposed to the client. They are also easily revocable. The trade-off is that they require a database lookup on every request, which can add overhead.

3. Hybrid Tokens

A common and secure pattern is to use a hybrid approach. This combines the best of both worlds. You'll often see this with OAuth 2.0:

Short-lived Access Token: This is a JWT, used for accessing resources. It's valid for a short time (e.g., 15 minutes), so if it's stolen, the attacker doesn't have much time to use it.
Long-lived Refresh Token: This is an opaque token, used to get a new access token once the old one expires. It's stored securely and can be revoked by the server if needed. This prevents a user from having to log in again every 15 minutes.

This approach balances the performance benefits of JWTs with the security and revocability of opaque tokens.

Conclusion: Which One Should You Use?

The choice of token depends on your application's needs. For a simple app where you want to keep things fast and stateless, a JWT might be the perfect fit. For a system that requires a high level of security and granular control over token revocation, a hybrid model is often the way to go. No matter which you choose, understanding how they work is a crucial skill for any developer building secure and scalable applications.

Understanding JWT: From Basics to Advanced Security

Fri, 28 Feb 2025 19:34:07 +0000

Introduction: The Evolution of Web Authentication

Early days of the web, authentication was relatively simple - users would log in, and servers would store their session information. However, as applications grew more complex and moved toward distributed systems and microservices, this traditional approach faced scalability challenges. JSON Web Tokens (JWTs), a revolutionary solution that changed how we handle authentication and authorization in modern web applications.

JWTs represent a paradigm shift in web security. Instead of the server keeping track of who's logged in, it issues a secure, self-contained token that holds all necessary information about the user. Think of it like a digital passport - once issued by a trusted authority, it can be verified anywhere without needing to check back with the issuing country. This approach has become increasingly important in our interconnected world of cloud services, mobile applications, and API-driven architectures.

Part 1: JWT Fundamentals

What is a JWT?

A JSON Web Token is a compact, self-contained way to securely transmit information between parties as a JSON object. Think of it as a digital passport that proves your identity and permissions in the web world. Each JWT contains three essential parts:

Header: The metadata section that describes the token's type and the signing algorithm used
Payload: The actual data (called "claims") about the user and additional metadata
Signature: A verification seal that ensures the token hasn't been tampered with

When these three parts are combined, you get something that looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The Anatomy of a JWT: Understanding the Structure

Before diving into how JWTs work, let's examine their structure in detail. A JWT consists of three distinct parts, each encoded in Base64URL format and separated by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

1. Header (The Metadata)

The header contains information about how the token itself is constructed. It typically includes:

{
  "alg": "HS256",    // The algorithm used for signing
  "typ": "JWT"       // The type of token
}

2. Payload (The Claims)

The payload carries the actual information about the user and token metadata. It contains claims, which are statements about an entity (typically the user) and additional metadata.

There are three types of claims:

Public Claims: Custom claims registered in the IANA JSON Web Token Registry
Private Claims: Custom claims created for sharing information between parties
Registered Claims: Predefined claims like:

{
  "iss": "auth.service.com",  // Issuer
  "sub": "user123",           // Subject
  "exp": 1516239022,         // Expiration Time
  "iat": 1516232822          // Issued At
}

3. Signature (The Verification Seal)

The signature is created by taking the encoded header, encoded payload, and a secret key, then applying the algorithm specified in the header. For example, with HMAC SHA256:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

This signature ensures that the token hasn't been modified in transit and verifies its authenticity.

How Does JWT Work in Practice?

The journey of a JWT follows a simple flow:

Authentication: When you log in successfully, the server creates a JWT containing information about your identity and permissions
Token Storage: Your application receives and stores this token
Authorization: For subsequent requests, your application includes this token in the header
Verification: The server checks the token's signature and grants access if it's valid

This process eliminates the need for the server to store session information, making JWTs perfect for modern, scalable applications.

Part 2: The Security Challenge

Common JWT Vulnerabilities

While JWTs are powerful, they're not immune to security issues. Here are the key vulnerabilities to watch out for:

Signature Verification Flaws

The signature is like a tamper-evident seal on a package. If the verification process is flawed or the secret key is weak, attackers can modify the token's contents without detection. This is particularly dangerous because it could allow unauthorized access to protected resources.

Algorithm Confusion Attacks

JWTs support multiple signing algorithms, including a dangerous "none" algorithm. If your server isn't configured properly, an attacker might trick it into accepting an unsigned token, effectively bypassing security checks altogether.

Client-Side Storage Risks

Many applications store JWTs in browser storage (localStorage or sessionStorage), making them vulnerable to Cross-Site Scripting (XSS) attacks. Think of this like keeping your house key in an obvious place - if someone gains access to your browser's JavaScript environment, they could steal your token.

The Revocation Challenge

Unlike traditional session tokens, JWTs don't have a built-in way to be invalidated before they expire. This means if a token is compromised, it remains valid until its expiration time, potentially giving attackers a window of opportunity.

Part 3: Building a Secure JWT Implementation

Essential Security Practices

Let's explore how to implement JWTs securely:

1. Secure Communication

Always transmit JWTs over HTTPS. This encrypts the token during transmission, preventing eavesdropping attacks. It's like sending sensitive documents through a secure courier service instead of regular mail.

2. Smart Token Storage

Instead of using browser storage, use HttpOnly cookies with the Secure flag enabled. This approach prevents JavaScript access to the token while ensuring it's only transmitted over secure connections. The cookie settings might look like this:

Set-Cookie: access_token=<token>;
            HttpOnly;
            Secure;
            SameSite=Strict;
            Path=/api

3. Token Lifecycle Management

Implement a robust token lifecycle strategy:

Set short expiration times for access tokens (15-30 minutes)
Use refresh tokens for obtaining new access tokens
Maintain a token blacklist for revoked tokens
Implement token rotation to regularly replace active tokens

4. Payload Security

Be mindful of what you include in your token payload:

Never store sensitive data like passwords or credit card numbers
Minimize the payload size to reduce overhead
Consider encrypting certain claims if they contain sensitive information

Advanced Security Measures

Going beyond the basics:

1. Fingerprinting

Include device or context information in the token to detect potential token theft:

{
  "sub": "1234567890",
  "fingerprint": "device_id|user_agent|ip_hash",
  "exp": 1516239022
}

2. Audience Validation

Specify and validate the intended recipient of the token to prevent token reuse across different services:

{
  "aud": "https://api.myservice.com",
  "sub": "1234567890",
  "exp": 1516239022
}

Part 4: The Future of JWT Security

Emerging Security Enhancements

The security landscape is constantly evolving, and JWT security is no exception. Here are some promising developments:

1. Quantum-Resistant Algorithms

As quantum computing advances, new signing algorithms resistant to quantum attacks are being developed. These will ensure JWTs remain secure even in a post-quantum world.

2. Dynamic Validation

Future implementations might include real-time validation systems that can instantly revoke tokens based on security events or user behavior changes.

3. Enhanced Standards

The JWT standard continues to evolve with new security features and best practices. Stay updated with the latest JWT specifications and security recommendations from the IETF.

Conclusion

JWTs represent a powerful solution for modern web authentication and authorization, but their security requires careful consideration and implementation. By understanding both the fundamentals and security challenges, and by implementing robust security measures, you can harness the benefits of JWTs while maintaining strong security.

Learn on JWT, OAuth, OIDC, and SAML: https://guptadeepak.com/demystifying-jwt-oauth-oidc-and-saml-a-technical-guide/

Quick Reference: JWT Security Checklist

✓ Use strong, unique signing keys
✓ Implement proper algorithm validation
✓ Store tokens securely (HttpOnly cookies)
✓ Set appropriate token expiration
✓ Implement token rotation
✓ Validate token claims thoroughly
✓ Monitor for security updates
✓ Use HTTPS exclusively
✓ Implement proper error handling
✓ Regular security audits

Securing Autonomous AI Workflows Through Advanced Single Sign-On

Fri, 28 Feb 2025 16:14:07 +0000

Single sign-on (SSO) for AI agents addresses the unique authentication challenges of autonomous systems by combining cryptographic identity management with AI-driven behavioral analysis. This approach enables secure, ephemeral access while maintaining auditability in dynamic AI ecosystems.

How AI Agents Handle SSO Requests

1. Authentication Flow for Autonomous Actors

AI agents initiate SSO through a machine-optimized OAuth 2.0 Device Flow:

Scope Declaration: Agents request task-specific OAuth scopes (e.g., data:read-only, api:limited-write) during token generation
Cryptographic Handshake: Authentication via X.509 certificates or hardware-backed keys instead of passwords
Context Binding: Tokens embed environmental parameters (IP range, geolocation, approved compute zone)

Security Enforcement:

# Example token validation logic for AI agents
def validate_ai_token(token):
    require_claims = [
        'exp', 
        'scope',
        'allowed_ips',
        'device_fingerprint'
    ]
    if not all(claim in token for claim in require_claims):
        raise InvalidTokenError

2. Session Lifecycle Management

Phase	AI-Specific Implementation
Initiation	SAML assertions include `AI-Agent-ID` and `Task-ID` metadata
Active Session	Tokens refresh every 5-15 minutes based on sensitivity tier
Termination	Automatic revocation via SCIM 2.0 API when task completes or deviates from expected behavior

3. Critical Security Layers

Layer	Implementation
Transport Security	Mutual TLS with pinned certificates
Token Protection	HSMs for key storage + AES-256-GCM encryption
Behavioral Analysis	ML models detecting anomalous token usage patterns

Types of SSO Workflows for Autonomous Agents

Machine Identity Management
AI agents authenticate through protocols like OAuth 2.0 or SAML using non-human credentials such as API keys, cryptographic certificates, or short-lived JWT tokens. Unlike human users, they bypass password-based authentication entirely.
Context-Aware Authentication
AI-enhanced SSO systems analyze multiple risk factors in real time:
- Device fingerprinting and IP reputation checks
- Behavioral patterns (e.g., typical API call frequency)
- Task-specific authorization scopes (e.g., data:read vs. data:write)
  Suspicious activity triggers step-up authentication or session termination.
Ephemeral Credential Lifecycle
Access tokens for AI agents expire within minutes/hours rather than days, limiting exposure windows. Systems like Konfuzio automatically rotate credentials using AI to detect weak patterns.

Security Advantages for AI Ecosystems

1. Dynamic Permission Chaining

Just-in-Time (JIT) Access:
Systems issue credentials valid only for specific API endpoints/duration
POST /token { "scope": "support-ticket:read", "exp": 900 }
Behavioral RBAC:
AI policy engines adjust permissions in real-time based on:
- API call patterns
- Data consumption rates
- Resource utilization metrics

2. Disconnection Protocols

Post-Task Termination Workflow:

Completion signal from agent orchestrator
IdP revokes all associated tokens via OAuth token revocation endpoint
Service providers flush local session caches

Automated Cleanup Policies:

# Example Kubernetes-style cleanup policy
automaticRevocation:
  conditions:
    - taskStatus: COMPLETED
    - inactivityWindow: 300s
  actions:
    - revokeTokens: true
    - rotateCredentials: true

SSO Benefits for Autonomous Agents

Reduced Attack Surface

Eliminates hardcoded API keys in favor of dynamically issued tokens
63% fewer credential-related vulnerabilities compared to traditional API access

Granular Access Control

Role-Based Access Control (RBAC) paired with AI-driven policy engines restricts agents to minimum necessary permissions
Example: A customer support bot might have ticket:read access but no database:write privileges

Enhanced Monitoring

Centralized audit trails map every AI action to specific machine identities
Behavioral analytics flag anomalies like unusual data access patterns

Key Implementation Challenges

Challenge	AI-Specific Consideration
Dynamic Permissions	Agents often require cross-system access that static RBAC struggles to manage
Legacy Integration	38% of enterprise systems lack modern SSO protocols, requiring custom connectors
Token Security	Compromised AI credentials could enable lateral movement; solutions include hardware-backed token storage

Implement Best Practices

Zero-Trust Session Validation
- Continuous posture checks using CNCF OpenPubkey standards
- 78% faster threat detection vs traditional methods
Composite Identity Verification
Combine machine credentials with environmental signals (geolocation, network trustworthiness) before granting access
SSO Protocol Selection
- SAML/OIDC: Preferred for enterprise systems with centralized IdPs
- OAuth 2.0 Device Flow: Optimal for headless AI agents
Automated Policy Enforcement
- Dynamically adjust permissions based on task context
- Revoke access instantly when anomalies exceed risk thresholds
Enterprise Deployment Pattern

graph TD
    A[AI Agent] -->|OIDC Request| B(SSO Gateway)
    B --> C{Policy Engine}
    C -->|Approved| D[Issues JWT]
    C -->|Denied| E[Triggers MFA/Alert]

6. Audit Trail

Immutable logs mapping tokens to:
- Source code commit ID
- Training data version
- Model hash

Future Evolution

Emerging standards aim to address AI-specific gaps:

Just-in-Time (JIT) Provisioning: Ephemeral credentials issued per-task
Quantum-Resistant Cryptography: Preparing for post-quantum security threats
Federated Learning Integration: SSO systems that adapt using decentralized behavioral data

As AI agents handle 34% of enterprise workflows by 2026 (Gartner), SSO becomes indispensable for balancing accessibility with security. Organizations adopting AI-optimized SSO frameworks report 41% fewer credential-related breaches while maintaining audit compliance.

Emerging Standards

NIST SP 800-213A:
- Requires AI agents to use separate IdP tenant from human users
- Mandates automated credential rotation every 72 hours max
ISO/IEC 27566 (Draft):
- Standardizes SSO claim formats for autonomous systems
- Defines ML-powered anomaly detection baselines