DEV Community: VinayKumar KsheeraSagar

Why Agent Tool Use is an Identity Problem, Not a Prompt Problem

VinayKumar KsheeraSagar — Sat, 31 Oct 2026 11:48:25 +0000

Originally published at invarcore.com/blog/why-agent-tool-use-is-an-identity-problem

Somewhere right now, an enterprise is deploying an autonomous agent with a system prompt that looks something like this:

You are a helpful database query assistant.
You must ONLY read records where tenant_id = 42.
Never run DROP, DELETE, or UPDATE.
Never disclose employee compensation records.
Always be polite.

Under the hood, the orchestrator has handed the LLM agent a raw PostgreSQL connection string with SUPERUSER privileges or an AWS IAM role with s3:* across the entire analytics data lake.

Let's be completely candid: this is not software architecture. This is cargo-culting safety through the medium of English prose. It is the cloud equivalent of giving a stranger a skeleton key to every room in your building, accompanied by a polite Post-it note asking them not to open the executive washroom.

If your authorization boundary depends on a 70-billion-parameter next-token predictor deciding to obey your instructions rather than an adversary's jailbreak prompt, you do not have a security model. You have a wish list.

1. The Confused Deputy Problem (Re-Invented in Python 3.12)

In 1988, Norm Hardy coined the term Confused Deputy to describe a security vulnerability where a program with legitimate authority is tricked by an unprivileged client into misusing its authority on the client's behalf.

For thirty years, systems architects built capability-based security, cryptographic tokens, and fine-grained authorization matrices (FGAP) specifically to eliminate confused deputies. We learned—painfully—that privilege must be tightly bound to intent.

Then generative AI arrived, and the industry collectively decided to pretend these lessons never happened. Consider what happens when Alice asks an orchestrator agent: "Summarize my open PRs and clean up stale test branches on GitHub."

When the agent calls the GitHub API, who is the caller?

Is it Alice? If the agent passes Alice's personal access token (PAT), it is impersonating Alice with 100% of her authority—including the power to delete production repositories or approve its own malicious commits.
Is it the agent? If the agent presents its own static machine service account, the destination server has no cryptographic proof that Alice ever authorized this specific call.
Is it the subagent? What if the orchestrator spins up three parallel workers to parse ASTs? Do all three inherit root?

2. The Bearer Token Lie

RFC 6749 bearer tokens were designed for a boring, two-party world: a human user logs in via a browser client, and the client presents an opaque string to a backend resource server. Possession of the token is proof of authority.

In autonomous agent topologies, however, execution graphs look like this:

User (Alice) ──> Orchestrator Agent ──> Specialized Worker Subagent ──> GitHub Tool API

If you pass Alice's bearer token down the line, you violate every principle of least privilege. The worker subagent now holds unconstrained authority across Alice's entire account.

If you instead mint an isolated token for each subagent without recording the delegation chain, you completely sever the enterprise audit trail. When an unauthorized commit lands on main, the audit log simply records: Action executed by agent-worker-4. Who authorized it? Why? Under what user intent? The chain of custody is gone.

3. The Real Wire Architecture: RFC 8693 Token Exchange

We do not need to invent speculative cryptographic protocols. The identity architecture community already solved this: it is called RFC 8693 (OAuth 2.0 Token Exchange).

Instead of handing an agent raw credentials or static bearer tokens, the orchestrator presents Alice's subject token to the Authorization Server and requests an attenuated, cryptographically bound delegation token, explicitly declaring its own actor identity:

POST /oauth/v2/token HTTP/1.1
Host: auth.acme.corp
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=eyJhbGciOi... (Alice's access token)
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&actor_token=eyJhbGciOi... (Agent-X's authenticated service identity)
&actor_token_type=urn:ietf:params:oauth:token-type:access_token
&scope=repo:read pull_requests:read
&audience=https://api.github.com

The resulting token issued by the authorization server carries the RFC 8693 act (actor) claim:

{
  "iss": "https://auth.acme.corp",
  "sub": "alice@acme.corp",
  "aud": "https://api.github.com",
  "scope": "repo:read pull_requests:read",
  "exp": 1730419200,
  "act": {
    "sub": "agent-orchestrator-9",
    "client_id": "agent-orchestrator-9"
  }
}

Notice what happens at the wire level:

Attenuated Authority: The subagent's scope is mathematically downscoped (repo:read, not repo:admin). Even if prompt injection compels the agent to issue a DELETE /repos call, GitHub rejects it at the HTTP boundary.
Audience Confinement: The token is cryptographically locked to https://api.github.com. If the agent is tricked into calling an attacker's webhook, the token is worthless.
Dual Identity & Non-Repudiation: GitHub knows the subject is Alice, but the actor executing the call is agent-orchestrator-9. The audit log preserves both identities without ambiguity.

4. The Non-Human Identity Trap: Revocation Cascades

Here is the dirty secret of modern identity servers: almost none of them handle delegation cascades properly.

Suppose Alice is terminated at 2:00 PM on Friday. The security team clicks "Deactivate User". Her primary access token is revoked via RFC 7009. Her SSO session dies instantly.

What happens to the background agent that exchanged her token at 1:55 PM with a 60-minute TTL?

In almost every major open-source identity server running in enterprise clusters today, downstream exchanged tokens are completely orphaned. They remain fully active and valid until cryptographic expiration (exp). An agent running an autonomous loop will continue mutating enterprise infrastructure for another 55 minutes after the user who authorized it has been escorted out of the building.

THE ARCHITECTURAL INVARIANT

An agent is never the subject; it is an untrusted actor executing under an attenuating, non-repudiable delegation contract that dies the instant user intent is revoked.

5. The Way Forward

If you are building multi-agent systems, stop treating tool security as a prompt engineering problem. Stop writing polite instructions in markdown system prompts and hoping the model doesn't hallucinate.

Treat every agent invocation as a cross-domain authorization boundary:

Enforce least-privilege capability confinement at the wire level.
Mandate RFC 8693 actor chains in Model Context Protocol (MCP) tool dispatch.
Ensure your identity plane supports downstream revocation cascades.

Boring protocols, sound mathematics, and deterministic invariants will protect your enterprise. System prompts will not.

Author: VinayKumar KsheeraSagar · Founder, Invarcore

Open-source verification engines & mathematical invariants for autonomous AI agents.

GitHub: github.com/invarcore • github.com/sagarv48

[Boost]

VinayKumar KsheeraSagar — Mon, 21 Sep 2026 13:52:55 +0000

VinayKumar KsheeraSagar

Sep 18

Why AI Agents Need Verifiable Evidence: Building an MCP-Native Retrieval Engine with PostgreSQL

#ai #mcp #python #opensource

3 min read

Hybrid retrieval in one Postgres query: RRF over tsvector + pgvector

VinayKumar KsheeraSagar — Mon, 21 Sep 2026 12:15:58 +0000

Dense vector search is great until your agent asks for parseAuthHeader and gets back three chunks about "authentication token handling" — semantically close, functionally useless. Same story with file paths, error codes, and compliance clause numbers. These are lexical needles, and embeddings blur them.

This isn't a niche complaint. XERJ has been picking up steam on the strength of "stop making agents grep," and Volcengine's OpenViking has ~38k stars for treating agent context as structured, addressable storage rather than a vector dump. Both are good. Both are also new infrastructure you now operate. XERJ in particular already does hybrid BM25 + kNN with RRF — if you're greenfield and happy to run a dedicated engine, genuinely go look at it.

I had a constraint they don't solve for: the evidence had to live in the same transaction as the data it describes, in a database my team already backs up and already knows how to restore at 3am.

The usual fix is to bolt on BM25 from a dedicated search service, then fuse results in application code. That means a second stateful cluster: its own backups, its own failure modes, and no transactional guarantee that your index agrees with your source of truth.

I wanted to know how far Postgres 16 + pgvector could get on its own. Turns out: all the way.

One engine, two retrieval paths

Knowledge Fabric runs full-text search over tsvector and dense search over an HNSW index in the same database, then fuses the two ranked lists with Reciprocal Rank Fusion:

**score = 1 / (60 + rank_lexical) + 1 / (60 + rank_vector)**

RRF only needs ranks, not scores, so you skip the entire problem of normalizing BM25 against cosine similarity. A chunk that places top-3 on both paths wins. A chunk that's #1 lexically and invisible semantically still surfaces — which is exactly what you want when the query is a function name.

One query. One backup. One consistency model.

Evidence you can verify, not just text you hope is right

This part matters more than it sounds. In an agentic setup, retrieved text isn't just context — it's the authorization premise for a state-changing tool call. If the agent reads a policy chunk and then executes a deploy, something needs to prove that chunk wasn't tampered with.

Every chunk gets a deterministic SHA-256 hash and a composite provenance digest, canonicalized per RFC 8785 so byte-level serialization differences don't produce different hashes for identical content. A downstream policy layer can then verify the agent acted on authentic evidence before approving execution.

It's an MCP server

retrieve_evidence, get_document, explain_retrieval — bounded tools over stdio and HTTP via FastMCP. Works with Claude Code, Cursor, or your own harness. explain_retrieval exists because "why did it return that?" is a question you will ask roughly forty times in week one.

Docker Compose quickstart, benchmarks, and the full implementation: https://github.com/sagarv48/knowledge-fabric

If you've tuned RRF in production — did you keep k at 60, or did you find your corpus wanted something different? I'm curious whether the default holds up on codebases with heavy identifier repetition.

Why AI Agents Need Verifiable Evidence: Building an MCP-Native Retrieval Engine with PostgreSQL

VinayKumar KsheeraSagar — Fri, 18 Sep 2026 04:59:50 +0000

Why standard RAG fails agentic workflows, and how we built Knowledge Fabric using PostgreSQL, pgvector, and FastMCP.

Most Retrieval-Augmented Generation (RAG) setups treat context retrieval as a simple black box: prompt in, cosine similarity ranking, top-k text dump out.

In conversational chatbots, a slightly noisy chunk is usually harmless. But in agentic architectures—where models make tool calls, plan execution steps, and trigger real-world actions—retrieval without provenance is a major vulnerability. If an agent cannot verify where an excerpt originated, what version of a document it reflects, or whether the text was modified, policy checks fail and downstream execution becomes unreliable.

To address this, we built Knowledge Fabric: an open-source, vendor-neutral evidence retrieval engine designed natively for the Model Context Protocol (MCP) and built on PostgreSQL with pgvector.

The Problem: Naive RAG vs. Agentic Evidence

When an agent needs context to answer an enterprise query or decide on an action, standard vector stores present three common issues:

Exact-Term Blind Spots: Pure dense vector search often misses exact identifiers (e.g., invoice IDs, function signatures, error codes).
Missing Citations & Provenance: Agents receive text strings without cryptographic hashing, source revision IDs, or bounding offsets.
Bloated Context Windows: Shoveling sprawling context into prompts increases latency and token costs while confusing agent decision boundaries.

Architectural Design: The Three-Tier Fabric

Rather than building an all-in-one monolith that handles planning, retrieval, and write executions simultaneously, we separate concerns into three distinct roles:

Knowledge Fabric (The Librarian): Collects, indexes, searches, and provides verifiable evidence packages with clear citations.
Intent Fabric (The Planner & Referee): Translates user intent and evidence into policy-validated plans.
Enterprise Adapters (The Controlled Doors): Read from external systems and execute approved write mutations.

Workflow:

Storage Engine: Standard Infrastructure First

We deliberately avoided introducing custom daemons or proprietary vector databases. Knowledge Fabric is built directly on PostgreSQL + pgvector:

Hybrid Search with Reciprocal Rank Fusion (RRF): Fuses PostgreSQL BM25-style lexical search (tsvector) with semantic vector embeddings (pgvector) to ensure exact keyword recall alongside conceptual relevance.
Evidence Packaging: Every retrieved passage includes document URI, offset boundaries, chunk hash, and retrieval explanation metadata.
Native FastMCP Interface: Exposes retrieval directly over stdio and HTTP endpoints for Claude Code, Cursor, Codex, and custom agent harnesses.

FastMCP Tool Surface

Knowledge Fabric exposes five core MCP tools:

retrieve_evidence: Performs hybrid search and returns bounded, cited evidence packages.
get_document: Fetches full document content and metadata by ID or URI.
list_sources: Inspects currently indexed collections and document trees.
explain_retrieval: Returns the scoring breakdown (lexical vs. vector RRF ranks) for an evidence query.
health: Confirms database connectivity and vector index status.

3-Minute Quickstart

You can test Knowledge Fabric locally using Docker Compose:

Clone and launch PostgreSQL with pgvector:

git clone https://github.com/sagarv48/knowledge-fabric.git
cd knowledge-fabric
docker compose up -d

Install dependencies & initialize the database:

python -m venv .venv
source .venv/bin/activate
pip install -e .
python -m knowledge_fabric.cli init-db

Run the FastMCP Server: python -m knowledge_fabric.mcp.server

You can now add the server to your Claude Desktop or Cursor MCP configuration:

{
  "mcpServers": {
    "knowledge-fabric": {
      "command": "python",
      "args": ["-m", "knowledge_fabric.mcp.server"],
      "env": {
        "DATABASE_URL": "postgresql://postgres:postgres@localhost:5432/knowledge_fabric"
      }
    }
  }
}

What's Next & Getting Involved

Knowledge Fabric is early and actively developed. We are currently refining local embedding pipelines (Ollama integration) and chunking strategies.

GitHub Repository: https://github.com/sagarv48/knowledge-fabric
Roadmap & Issues: Check out our open issues for connector ideas and hybrid search tuning.

If you are building with MCP or experimenting with agent architectures, I would love to hear how you currently tackle citation and evidence verification in your workflows!