Agent Guard 1.2.0

Agent Guard 1.2.0

Agent Guard now works out of the box with the model providers and agent frameworks people
use. A new package, @shieldaai/agent-guard-adapters, connects the guard to Claude, OpenAI,
Gemini, Bedrock, the Vercel AI SDK, the OpenAI Agents SDK, LangChain and any MCP client.
@shieldaai/agent-guard, -mcp, -scenarios, -executor and the experimental
@shieldaai/agent-map are unchanged apart from their version. All six packages move to
1.2.0 together.

Why

Before 1.2.0, every application had to write the same code to use the guard with a model:
a dispatcher that sends each tool call through prepare and execute, a place where
actions wait for a person, a check of the model's arguments, and a conversion between the
guard's results and each provider's tool-call format. The only ready-made integration was
MCP. That code is easy to get subtly wrong, for example by showing the model a tool
definition nobody approved, or by passing a host error message to the model. 1.2.0 ships it
once, tested, for each integration.

What is new

Integrations

Integration	Adapter
Anthropic Messages API (Claude)	anthropicTools, anthropicToolResults
OpenAI Responses API	openAIResponsesTools, openAIResponsesToolOutputs
OpenAI Chat Completions and compatible APIs (Groq, Mistral, OpenRouter, vLLM, Ollama, ...)	openAIChatTools, openAIChatToolMessages
Google Gemini (@google/genai)	geminiTools, geminiFunctionResponses
Amazon Bedrock Converse	bedrockTools, bedrockToolResults
Vercel AI SDK	aiSdkTools
OpenAI Agents SDK	openAIAgentsTools
LangChain.js and LangGraph.js	langChainTools
Claude Code, Claude Desktop, Cursor, VS Code, the Claude Agent SDK (MCP clients)	registerMcpServerTools, mcpServerTools
OpenTelemetry, JSON log shippers	openTelemetryDecisionHook, jsonLinesDecisionLogger
Zod, Valibot, ArkType (Standard Schema)	standardSchemaParser

The adapters package has no third-party runtime dependencies. Framework adapters take the
framework's own factory function as an argument (for example tool from @openai/agents),
so it never pins a framework version.

Building blocks

• One dispatcher (createDispatcher). Every outcome is one of four statuses:

  • ok: the call ran;
  • denied: nothing ran, with a message that tells the model what to do next;
  • waiting_for_approval;
  • failed: the effect is unknown.

  Errors from host code are reported to your onHostError hook. The model gets HOST_ERROR
  without detail. The dispatcher works with the core guard, the durable executor and the
  executor's task client.

• An approval queue (ApprovalQueue) for actions that wait for a person.

  • Each task gets its own share of the queue.
  • Actions of a revoked or expired task are dropped.
  • Dispatchers can return at once, or wait for the decision with a time limit.

• Tools the model sees are the ones you approved. toolSpecs reads names, descriptions
  and schemas from the guard's approved registrations. registerApprovedTools can pin
  fingerprints, so a changed tool fails start-up. defineTool types a tool's arguments.

• Argument checks from the same schema the model sees. jsonSchemaParser enforces a
  JSON Schema as the tool's parse. It refuses unsupported keywords, and regular expressions
  that can take exponential time, when the parser is built.

• Policies. combinePolicies with denyTools, requireApprovalForTools,
  requireApprovalForExternal, requireApprovalAfterUntrusted, withinHours, denyWhen and
  requireApprovalWhen. RateLimiter limits a tool across all tasks of a tenant or principal.

• An agent-guard-explain command that explains any denial code.

Documentation and examples

• Connect your model or framework: every integration, with the
  few lines each one needs.
• The README leads with the integrations table.
• examples/model-adapters.mjs runs one model turn in
  five provider formats. examples/mcp-guarded-server.mjs
  is an MCP server with guarded tools, for example for Claude Code. Both run offline.
• Support and limits lists
  what the adapters do not do.

Upgrading from 1.1.1

Nothing changes for existing code. Move every Agent Guard package you use to 1.2.0 and, to
use the integrations, add @shieldaai/agent-guard-adapters@1.2.0.

Known limits

• ApprovalQueue and RateLimiter keep their state in memory, in one process. A restart
  drops pending approvals (nothing runs) and resets rate counts.
• A rate limit can be exceeded by the number of calls already in flight when it is reached.
• The check for exponential regular expressions is deliberately cautious. It refuses some
  safe patterns, such as ^[a-z]+(\.[a-z]+)*$, unless allowNestedQuantifiers is set. It
  does not detect overlapping alternatives such as (a|a)+.
• The provider adapters were run against the providers' request and response formats and
  type-checked against their official SDKs, not against live endpoints.
• The limits of 1.1.0 and 1.0.0 still apply.

Verification

Run locally before the pull request:

• npm run check: 1,968 tests, 0 failed, 11 skipped (Docker, Linux-only and Windows-only
  cases). The packed packages pass in a clean project. That includes the adapters README
  example compiled with strict TypeScript.
• scripts/verify-adapters-real-packages.mjs passed:
  • It ran the adapters against ai 7.0.173 (a full generateText loop), @openai/agents
    0.22.0, @langchain/core 1.4.1 with @langchain/langgraph 1.7.4, and zod 4.6.7.
  • It type-checked the provider adapters against @anthropic-ai/sdk 1.8.0, openai 7.57.0,
    @google/genai 3.3.0 and @aws-sdk/client-bedrock-runtime 3.1169.0.
• The MCP adapter ran with a real MCP client and server (MCP TypeScript SDK 2.4), in memory
  and over stdio.

CI and CodeQL must pass on the pull request and on the merge commit before publishing
(releasing, step 5).

Agent Guard 1.1.1

Agent Guard 1.1.1

A documentation-only patch of @shieldaai/agent-guard, -mcp, -scenarios, -executor
and the experimental @shieldaai/agent-map. The code, types and behavior are the same as in
1.1.0. All five packages move to 1.1.1 together, as they always do.

What changed

• The npm page for the core package now says what problem Agent Guard addresses before
  it says what it does: agents read text they did not write, a hidden instruction can mislead
  them, and the guard limits what a misled agent can do. It links to the
  OWASP Top 10 for Agentic Applications mapping.
• The core package description on npm leads with that outcome.
• The repository README points from its problem section to the OWASP table.
• The release procedure says to publish from a full clone. npm does not record gitHead
  when it publishes from a git worktree checkout, which is why
  @shieldaai/agent-guard@1.1.0 has none.
• The Python Cartography integration (in the repository, not on npm) locks dnspython
  2.9.2 for GHSA-vvf4-9x63-8xvv.
  None of the npm packages use it.

Upgrading from 1.1.0

Nothing to do. Changing 1.1.0 to 1.1.1 in your dependencies changes no code. Keep all
the packages you use on the same version.

Known limits

The limits of 1.1.0 and 1.0.0 still apply; see also
Support and limits.

Verification

All 19 checks passed on the release candidate 8fd8ab6
(pull request 62, CI run
43506611372): npm run check
on Node 22, 24 and 26 on Linux and on macOS and Windows; the browser checks in Chromium,
Firefox and WebKit; the Neo4j integration tests; the Docker isolation and production-image
checks; the Python dependency audit; CodeQL with no open alerts. CI and CodeQL also passed on
the merge commit 223d865 (CI run
43510071352).

Two CI fixes landed with the approval (pull request 64),
neither in published code: the browser jobs' mirror check accepts GitHub's AWS-hosted runners, whose
first apt mirror is the regional ec2.archive.ubuntu.com archive rather than the Azure one, and a
viewer test now waits for both requests it checks.

Agent Guard 1.1.0

Agent Guard 1.1.0

A minor release of @shieldaai/agent-guard, -mcp, -scenarios, -executor and the
experimental @shieldaai/agent-map. It adds one feature, asked for by a reader of the 1.0
announcement (issue 57): reviewers can
see what changed in a tool definition before they approve it again. The 1.0 API is
unchanged. The full list is in the changelog.

What is new

In 1.0 a changed tool was refused until its new fingerprint was approved, but the guard
could not say what had changed. Now it keeps the approved definition and compares.

const fingerprint = guard.registerTool(changedDefinition);
const review = guard.toolChanges('files.read');
// review.status === 'changed'
// review.changes:
//   { path: '/description', kind: 'changed', before: '…', after: '…', hints: ['INSTRUCTION_TEXT'] }
//   { path: '/inputSchema/properties/upload_to', kind: 'added', after: { type: 'string' }, hints: ['SCHEMA_FIELD_ADDED'] }
guard.approveTool('files.read', fingerprint, { reviewedAgainst: review.approvedFingerprint ?? null });

• Core. toolChanges(name) lists each changed JSON path of the definition with the
  approved and the new value. diffToolDefinitions() does the same for any two
  definitions. approveTool() takes an optional reviewedAgainst, so an approval made
  against a comparison that is no longer current is refused.
• Hints. Changes that often matter are marked: new instruction-like text, invisible
  characters, a new or loosened schema field, a weakened guard flag. They are heuristics
  for a person. They block nothing.
• MCP. connection.operationChanges(name) shows what the server changed since the
  operation was last approved, after a refresh or a reconnect, with both descriptor digests.
• Executor. Approved definitions are stored in the ledger with who approved them and
  what they replaced, so the comparison works after a restart.
• Scenarios. Catalog 1.4.0 adds the diff to S06.
• Agent Ops. Maintenance shows the comparison for the service's own tool, until the
  next restart.

API contract has the exact types.

Known limits

• The comparison covers a tool's definition: name, description, input schema, metadata and
  flags. It never shows a change in what the tool's code does.
• Hints are heuristics. They miss hostile text and flag harmless text. An unmarked change
  is not a safe change.
• Values in a comparison are the tool's or server's own text. Show them as data: escape
  them, and do not pass them to a model as instructions.
• A definition over 64 KiB (configurable up to 1 MiB) is approved by fingerprint only, as is
  one that does not fit the executor's budget for kept definitions (an eighth of the ledger). The
  guard says so (status: 'unavailable') instead of showing a diff.
• The in-memory guard forgets approved definitions on restart. Use the executor to keep them.
• A ledger written by 1.0.0 has no approved definitions: each tool reports first_approval
  until it is approved once with 1.1.0.
• The limits of 1.0.0 still apply; see its release notes and
  Support and limits.

Verification

All 19 checks passed on the release candidate 781a1ad
(pull request 58): npm run check on
Node 22, 24 and 26 on Linux and on macOS and Windows; the browser checks in Chromium,
Firefox and WebKit; the Neo4j integration tests; the Docker isolation and production-image
checks; CodeQL with no open alerts. CI and CodeQL also passed on the merge commit 8fd7c76.
Main CI run: 43412403731.

The nightly constrained-observer timing run (one logical CPU) did not pass on 8fd7c76. It
is not a required check, and that profile is not supported; see
Support and limits.

Upgrading from 1.0.0

No code change is needed.

• Ledger. formatVersion stays 1. A 1.0.0 ledger opens as it is, and 1.0.0 can still
  open a ledger that 1.1.0 wrote. 1.0.0 does not maintain the approved-definition record,
  so after going back to 1.0.0 and forward again a comparison can be against an older
  approval; toolChanges(name).approval.approvedAt shows which.
• MCP. If you store reviewed descriptorDigest values yourself, that keeps working.
  With operationChanges() the guard does the comparison for you.
• Scenario reports. catalogVersion is 1.4.0. A custom adapter without toolChanges
  still passes; it runs the 1.3.0 checks of S06.
• Agent Ops (source builds). GET /api/maintenance adds toolDefinition; the bundled
  page requires it, so deploy the service and the page together.

Agent Guard 1.0.0

Agent Guard 1.0.0

The first stable release of @shieldaai/agent-guard, -mcp, -scenarios and
-executor. @shieldaai/agent-map is published at the same version but stays
experimental. The last published version was 0.1.0-alpha.3; everything since then is
in this release. The full list is in the changelog, grouped by
package.

What 1.0 promises

Package	Promise
@shieldaai/agent-guard, -mcp, -scenarios	Root exports follow semantic versioning.
@shieldaai/agent-guard-executor	Root, /sandbox, /pilot and /ops follow semantic versioning. Every 1.x executor opens ledgers written by earlier 1.x versions and by 0.1.0-alpha.3; downgrade is not supported. /inventory is experimental; /internal has no promise.
@shieldaai/agent-map	Experimental. Its API and graph model may change in a minor release.

Agent Guard limits what a misled agent can do through the calls routed to it. It does not
detect prompt injection and it is not a sandbox. Risks and how Agent Guard handles
them and Support and limits say what is and is
not covered.

What is in 1.0

If you did not use the alphas, this is what the release contains:

• The guard (@shieldaai/agent-guard): tools you register and approve, tasks with
  grants on exact resources, tenants and recipients, approvals tied to one exact action,
  budgets, delegation to sub-tasks, and revocation. In memory, in one process, with no
  third-party runtime dependencies.
• MCP adapter: the tools, resources and prompts of a Model Context Protocol server
  behind the same checks, with a digest for noticing a changed tool definition.
• Durable executor: the same checks with an encrypted SQLite ledger, a token per task
  over HTTP, governed memory and an optional Docker profile for untrusted code.
• Scenarios: thirteen hostile and ordinary scenarios (twenty-six cases) to run against
  your own integration.
• Experimental: Agent Map, an inventory of declared agents and what they can reach.

New since the alphas

• Outside-content labels (readsUntrusted, untrustedContext, sendsExternal) in core,
  executor, MCP and governed memory, off by default.
• executeDetailed(), retireTask(), unapproveTool(), unregisterTool(), onDecision,
  limits, monotonicClock, GuardErrorCatalog and isGuardError() in core.
• A restart-stable descriptorDigest for pinning reviewed MCP tool definitions.
• A trusted read-back of prepared actions for review screens
  (executor.preparedAction(), POST /v1/admin/action).
• An explicit executor ledger format version with migrations.
• Agent Map boundary flags, outside-guard reach, discovery leads and host manifest v3.
• Scenario catalog 1.3.0 (thirteen scenarios, twenty-six cases).

Known limits

• The inventory observer is experimental; one logical CPU with 250 ms polling is not
  supported.
• Agent Map full-graph reads are estimated to work up to roughly 150 agents with default
  limits and roughly 800 at the maximum. Limits above the defaults have not been run against
  a Neo4j database, and the 5-second read deadline does not grow with them: test your
  largest reads against your own database first.
• Agent Ops needs a per-client limit at the load balancer or firewall when clients share an
  address or an attacker controls many addresses.
• The core keeps state in memory in one process; the executor is single-owner. There are
  no distributed quotas, no distributed revocation and no high availability.

Verification

All 19 checks passed on the release candidate 424810a
(pull request 56): npm run check on
Node 22, 24 and 26 on Linux and on macOS and Windows; the browser checks in Chromium,
Firefox and WebKit; the Neo4j integration tests; the Docker isolation and production-image
checks; CodeQL with no open alerts. Main CI run:
43310105088.

Upgrading from 0.1.0-alpha.3

Core and executor

• Root aliases are gone. Import the internal building blocks from
  @shieldaai/agent-guard/internal, and the executor's sandbox, inventory, pilot and
  operator names from /sandbox, /inventory, /pilot and /ops.
• Handler errors (executor). Whatever a host tool handler throws, execute() now fails
  with TOOL_FAILED, or EXECUTION_ABORTED if the call was canceled, revoked or past its
  deadline. In the alphas a GuardError or ExecutorError thrown by a handler reached the
  caller with its own code. That code is now in error.detail; match on detail instead of
  code. The built-in memory, model, HTTP, private-file and sandbox tools keep their codes.
• Callbacks inside built-in tools. An error thrown by a host callback inside a built-in
  tool (model complete, outbound credential, sandbox onResult, artifact broker clock)
  is always TOOL_FAILED with the error's code as detail.
• Aborted handlers. A handler that is aborted before it performs its effect must throw
  (for example signal.throwIfAborted()). A handler that returns normally is taken to have
  performed the effect and is reported as EXECUTION_ABORTED with detail EFFECT_COMMITTED.
• Executor task server statuses. Denials use 401, 403, 404, 409, 429 and 503 instead
  of 400, and the body adds retryable. Upgrade ExecutorClient and the server together.
  requestsPerMinute counts only task requests that authenticated.
• Failed revocation. revokeTask() whose ledger write fails throws OPERATION_FAILED
  with detail: 'REVOCATION_NOT_DURABLE' (the store error is the cause), and
  POST /v1/admin/revoke answers 503 with "retryable": true and that detail. The task
  is denied in the running process and the revocation is recorded by the next ledger write
  that succeeds. Treat it as "not revoked yet" and repeat the call: if the process exits
  before any ledger write succeeds, the revocation is lost.
• Tool registration at startup. Registering an unchanged tool after a start no longer
  writes a TOOL_REGISTERED event or raises the tool's revision. Approvals are still
  withdrawn at every start.
• ADMITTED status. execution() no longer returns ADMITTED; an admitted action is
  RUNNING at once. Remove code that waits for ADMITTED. The value stays in
  ExecutionStatus because alpha ledgers can contain it; they still open and recover. The
  ACTION_ADMITTED audit event is unchanged.
• Receipt retention. Settled receipts are now kept per task family (maxReceiptsPerFamily,
  default 64) and per tenant (256); the alphas kept 256 for the whole ledger. An evicted
  receipt reads as status: 'PRUNED' with its outcome and charged. Once its stub is
  evicted too (256 per family, 1,024 per tenant), execution() returns status: 'PRUNED'
  with no outcome, and later fails with INVALID_PREPARED. Do not assume outcome is
  present. audit() keeps 256 events per tenant by default (maxRecentEventsPerTenant,
  up to 1,000) instead of one shared ring of 1,000.
• Ledger soft limit. Calls that add state (createTask, delegateTask, prepare,
  approve, execute, registering a new or changed tool, memory writes) fail with
  STORE_CAPACITY_EXCEEDED and detail: 'SOFT_LIMIT' once the ledger would pass
  maxLedgerBytes minus a reserve of one eighth, at most 1 MiB: 15 MiB with the default
  16 MiB. Revoke, cancel, settlement and reconcile use the reserve; if that is full they
  drop the oldest half of the audit events. Archive or raise maxLedgerBytes earlier than
  you did with the alphas. A ledger past its soft limit still starts and can register its
  existing tools, revoke, reconcile and archive.
• Path rule. Paths in artifact receipts and build-artifact policy must be at most 240
  UTF-8 bytes in Unicode NFC (they could be 1,024 characters). Sandbox and private-file
  paths are measured in bytes, not characters, so a non-ASCII path under 240 characters can
  now be refused. A receipt signed by an alpha with a longer path fails ARTIFACT_INVALID
  and a policy entry fails BUILD_PROVENANCE_INVALID: shorten the path and issue them again.
• Ledger format. The executor writes formatVersion 1 when it opens an alpha ledger.
  An alpha build still opens that ledger only while it stays at schema 1; retiring or
  archiving a task, key custody and the recovery mirror raise the schema, and the alphas
  refuse it then. Downgrade is not supported.
• Delegation errors. DELEGATION_DENIED now has a detail naming the exceeded limit.

MCP adapter

• Error names. A non-object argument value fails with ARGUMENTS_INVALID;
  INVALID_ARGUMENTS no longer exists.
• failureReason. A malformed name advertised by the server is reported as
  REGISTRY_REJECTED (or SCHEMA_INVALID in skipped[].reason), not
  INVALID_CONFIGURATION. After the transport closes unexpectedly, failureReason is
  CONNECTION_UNAVAILABLE, not undefined.
• VerifiedMcpHttpSession.connect() rejects bad options with INVALID_CONFIGURATION or
  REGISTRY_LIMIT before any network call; handle these separately from
  AUTHORIZATION_DENIED.
• Reviewed digests. descriptorDigest does not cover the server. If you store reviewed
  digests keyed by remote name only and connect to more than one server, key them by server
  ID and remote name.

Agent Map

• Neo4j 5.23 or later is required.
• Sort order. Listings sort by name in Unicode code-point order, field by field. Do not
  keep page offsets across the upgrade.
• Policy evidence that was not evaluated. Read policyCoverage before policyEvidence:
  an empty list with status unknown was not evaluated. get_agent_inventory reports
  counts.policies and the policies section total as null in that case.
• **Degraded answers inst...

Agent Guard 0.1.0-alpha.3

Agent Guard 0.1.0-alpha.3 publishes all five npm packages under the alpha tag from commit 55b577bf3fb0c2c99eff2f4102d8e15bd8401682.

This release hardens authorization, exact approval and workspace-file capture; adds independently retained rollback witnesses, credential-bound MCP sessions, signed build/pilot evidence and provider-evaluation tooling; and improves Agent Map recovery, mobile navigation and installed command launchers.

Detailed changes and deployment boundaries · Protection design · Engineering review

Validation for the released source:

• 926 local workspace tests passed with zero skips, followed by installed-package consumer checks.
• Chromium verification covered ten UI states and four mobile views, with zero axe violations and page errors.
• Merged-commit CI passed Linux Node 22/24/26 and native macOS/Windows checks. The macOS job passed on retry after the initial attempt could not acquire a hosted ARM runner. Windows file-reader tests cover exact bytes, path aliases and concurrent junction changes; optional Docker and POSIX-only checks retain their declared platform skips.
• CodeQL, dependency review, Cartography integration and the Cartography pilot passed at their recorded revisions. The exclusive-create rollback test fixture has one documented false-positive disposition; no scan rules were disabled.
• All five registry tarballs match the reviewed local archives, record the release commit as gitHead, and pass fresh registry-installed consumer checks. GitHub's build artifacts have byte-identical uncompressed tar streams; compressed bytes differ between build environments.

The attached verification record includes registry integrity hashes, package checksums, CI references and tags. SHA256SUMS covers the five registry tarballs and that record.

Package	Published alpha	Preserved latest
@shieldaai/agent-guard	0.1.0-alpha.3	0.1.0-alpha.0
@shieldaai/agent-guard-mcp	0.1.0-alpha.3	0.1.0-alpha.0
@shieldaai/agent-guard-scenarios	0.1.0-alpha.3	0.1.0-alpha.0
@shieldaai/agent-guard-executor	0.1.0-alpha.3	0.1.0-alpha.2
@shieldaai/agent-map	0.1.0-alpha.3	0.1.0-alpha.2

Install exact versions or @alpha while the SDK remains experimental. The private viewer and Python integration remain separate source components. Production deployment, full native Windows Docker isolation, operator studies, paid model trials and physical storage-failure validation remain deployment-specific work. This release does not claim deployment certification or trusted-publisher provenance.

Agent Guard 0.1.0-alpha.2

Agent Guard lets a host application restrict an AI agent to the tools and resources its task needs. This alpha adds a durable executor and Agent Map, which shows teams the permissions and tool connections captured in their inventory.

All five npm packages are available at 0.1.0-alpha.2 under the alpha tag.

• Core checks task permissions, approvals and budgets.
• MCP applies host approval and authorization to connected tools.
• Scenarios tests allowed and forbidden actions.
• Executor runs governed actions and preserves authority state across restarts.
• Agent Map provides scoped inventory queries over HTTP and MCP.

The first three packages retain latest at 0.1.0-alpha.0. npm assigned both alpha and latest to 0.1.0-alpha.2 for the first executor and Agent Map publications. The viewer and Python collector are separate repository components.

Agent Map command workaround. On macOS, the two npm command shortcuts exit with status 0 without running their entry points. The launchers work when invoked by their relative file paths from the project that installed the package. Use the applicable command with your host configuration.

node node_modules/@shieldaai/agent-map/dist/cli.js --config HOST_CONFIG.json
node node_modules/@shieldaai/agent-map/dist/identity-cli.js --config PRIVATE_HOST_CONFIG.json

All five registry tarballs match the attached files byte for byte and record release commit e8d8e82b31d7e4c60d565d9d37721953cc33c048. A fresh registry installation passed declaration and README compilation, MCP and executor runtime checks, scoped reference queries, and the HTTPS/OIDC consumer. The attached verification report records the failing shortcut checks and the passing direct launchers.

Release PR · CI · CodeQL · Cartography integration

Agent Guard 0.1.0-alpha.1

Agent Guard 0.1.0-alpha.1 is an experimental update to all three npm packages.

The core now rejects stale custom-policy decisions after concurrent task changes, checks deadlines when handlers settle, and bounds JSON normalization before excessive allocation. The conformance suite detects premature dispatch and incorrect cost settlement. MCP integration tests exercise the official SDK, and package checks compile the public declarations and README examples in a clean consumer.

Install the packages you need with the alpha tag or exact version:

npm install @shieldaai/agent-guard@0.1.0-alpha.1
npm install @shieldaai/agent-guard-mcp@0.1.0-alpha.1
npm install @shieldaai/agent-guard-scenarios@0.1.0-alpha.1

Published from commit 86cf5902acbbc029b0872060c1906cc25964ec5d. All three packages record that gitHead; registry tarball bytes and integrity hashes match the release artifacts. The alpha tag points to this release, while latest remains on 0.1.0-alpha.0.

Validation includes 121 tests, all 20 conformance variants, packed declarations and README examples, an MCP consumer, and a fresh consumer installed from the public registry. CI and CodeQL passed on the release commit; dependency review passed on the final pull-request head.

This alpha keeps authorization state in one process. It does not provide distributed enforcement or a production security guarantee. Remote cancellation, credentials and resource-side limits remain the host's responsibility. The packages have registry integrity checks but no build provenance attestation. See the threat model and release review for scope and limitations.

Agent Guard 0.1.0-alpha.0

Initial experimental alpha of the ShieldaAI Agent Guard TypeScript packages for Node.js 22+.

• @shieldaai/agent-guard: scoped tool execution, immutable prepared actions, exact approvals, tenant and recipient gates, sensitivity tracking, and shared local budgets.
• @shieldaai/agent-guard-mcp: MCP tool registration with explicit metadata approval and host-defined resource resolution.
• @shieldaai/agent-guard-scenarios: ten protective scenarios, each with malicious and benign executable fixtures.

Install the alpha:

npm install @shieldaai/agent-guard@0.1.0-alpha.0 @shieldaai/agent-guard-mcp@0.1.0-alpha.0 @shieldaai/agent-guard-scenarios@0.1.0-alpha.0

All packages use the alpha dist-tag. npm also assigned latest to this initial version, and rejected an authenticated attempt to remove that tag. Both tags currently point to 0.1.0-alpha.0; the release remains experimental. Use @alpha or an exact version explicitly. The core has no third-party runtime dependencies. Source is licensed under Apache-2.0.

Validation: all 80 tests and package-consumer checks passed. A fresh public-registry installation also passed the MCP dispatch check and all 20 conformance cases across the ten scenarios. Published tarball integrity matches the locally packed artifacts.

This alpha keeps state in one process and requires trusted host integration. It is not an OS sandbox or a universal prompt-injection detector. See the repository's threat model for deployment requirements and limitations.

GitHub-hosted CI is currently blocked by the GitHub account's billing lock; the local Node.js 22, 24, and 26 checks passed.