Skip to content

Blog

Tenant-Scoped Audit Logs for AI Agent Tool Calls

A tenant-scoped audit log for an AI agent's tool calls exists to answer two questions an incident reviewer puts to you in the same breath: show me every action your system took for Acme, and prove that record wasn't edited after the fact. Both are easy to wave at and hard to actually satisfy. A general trace store can usually show you something about Acme, but "every action" means the tenant has to be a field you can filter on cleanly — not a tag one call site set and another forgot. And "prove it wasn't edited" means the trail needs integrity you can hand to a third party, not your assurance that the database looks fine. This post shows how to produce a slice of the trail that belongs to exactly one customer, and hand it over with a proof it wasn't altered.

  • in Runtime
  • 10 min read

Time-Travel Debug an AI Agent by Rewinding State

To time-travel debug an AI agent, you rewind its recorded history to the exact step before it did something baffling, rebuild the state it was actually looking at, and replay its decisions deterministically — instead of squinting at stdout and guessing. When a request/response function misbehaves you set a breakpoint and re-run it. An autonomous agent gives you neither luxury: it woke itself on a trigger you didn't watch, called an LLM whose output you can't reproduce, mutated its own state across dozens of invocations, and fired a side effect you now have to explain. This post shows how a Promptise journal plus its rewind and replay engines turn "why did it do that?" into a reproducible postmortem, and where that differs — honestly — from LangGraph's graph-state time-travel.

Why trim_messages Drops Facts Your Agent Still Needs

Put trim_messages vs a facts ledger side by side on a deep tool loop and the difference stops being academic: trimming evicts messages by token or message count, so it can throw away the exact record the model still needs three turns later — while a ledger keeps that fact and drops the duplicates instead. When a tool-calling agent balloons in the middle of a long task, the reflex is to reach for one of two stock helpers: trim the message history, or summarize it. Both bound the transcript. Both also have a failure mode that only shows up on the tasks that matter most — the deep ones. This post compares those helpers head-to-head with Promptise Foundry's context_scope="ledger", a last-value-wins facts ledger that deduplicates repeated tool calls and cache-serves a repeat instead of re-running it, with no extra model call.

Zero-trust: verify the calling agent, not its name

In a zero-trust agent mesh you must verify the calling agent server-side — cryptographically, on the resource that receives the call — because a self-asserted agent name in a request body is trivial to forge. Agent A tells your billing server "I am billing-bot"; your server believes it; a compromised or misconfigured Agent B says exactly the same thing. If the only thing standing between a caller and issue_refund is a string it chose for itself, you have no security boundary at all — you have a naming convention.

  • in MCP
  • 8 min read

Why a Small MCP Tool Change Broke Every Connected Agent

To version MCP tools without breaking clients, you have to treat a tool's schema as a published API contract — because that is exactly what every connected agent already assumes it is. An agent does not read your source code. It reads the input_schema your server advertises, builds a function call to match, and trusts that the shape it saw at discovery time is the shape you will accept at call time. Rename one field from customer to customer_id, tighten filters from optional to required, or drop a property some prompt still references, and every agent already in flight starts emitting arguments your handler rejects. Nothing crashed on your side. You just changed the contract out from under callers who never agreed to the new terms.

Who Approved That AI Refund? Reviewer Attribution

When someone asks who approved this ai agent action — the $5,000 refund your agent issued to order A-1 at 3 a.m. — the honest answer is often a shrug, a Slack screenshot, and a log line that says the call succeeded. That is not reviewer attribution; that is a story. This post covers the provenance of an approval decision: what actually lands on a tamper-evident audit log when a human signs off, and whether that record can survive an incident reviewer who does not trust your good intentions.

What Is Workload Identity for AI Agents?

Workload identity for AI agents is the practice of giving every agent a stable, verifiable identity of its own — minted by the identity provider you already run — instead of handing the whole fleet one shared API key. If you deploy more than one agent, you have probably already felt the gap: your logs say "the model" did something, your audit trail can't name which agent hit which tool, and every agent holds the same credential so every agent has the same blast radius. By the end of this post you will know exactly what workload identity means for agents, why it is the same problem enterprises solved for services years ago, and how to give your first agent a real identity with no new secrets to manage.