@ory/argus 1.0.1 → 1.1.0

package/assets/skills/ory-build-agent/SKILL.md

@@ -361,7 +361,8 @@ PKCE flow, permission tuples, and activity events are all visible:
    `jq` — you
    should see `user.auth` → `agent.auth` → `permission.check` →
    `tool.complete` for every call.
-5. Promote to enforce once the tools are granted. The posture is a
+5. Native tools are allowed unless explicitly blocked. Promote to enforce once
+   the block policy is ready. The posture is a
    permission on the Ory project, read on every session — an admin sets it
    in the Ory Console (Agent Security); see the resolved value with
    `... permissions` via any harness CLI (same shared config file).
@@ -376,9 +377,9 @@ For full env-var coverage (including the user/agent split,
 - It does not generate the agent. The user owns the agent loop, tool
   catalog, and deployment shape. This skill only drops `@ory/argus` into
   whatever they already have.
-- It does not grant permissions. Those are provisioned in the Ory Console
-  (Agent Security); `@ory/argus` only reads them. Locally, the dev stack's
-  seed step grants the catalog for you.
+- It does not write permissions. Native-tool blocks and MCP grants are
+  provisioned in the Ory Console (Agent Security); `@ory/argus` only reads
+  them. The local seed writes no baseline native-tool grants.
 - It does not adapt one of the existing harness plugins (`@ory/claude-code`,
   `@ory/codex`, `@ory/gemini-cli`, `@ory/openclaw`, `@ory/opencode`). Those
   are for users running those harnesses — not building a custom agent.

package/assets/skills/ory-temporal-worker/SKILL.md

@@ -244,19 +244,19 @@ The Workflow itself produces no Ory activity — only its Activities do.
 
 ## Step 6 — Promotion from observe to enforce
 
-The worker starts in `observe` mode by default: denies pass through but each is
-recorded as a `permission.observe_deny` activity event. Once the user has confirmed
-the deny set is what they expect, an admin promotes the posture to `enforce` in
+The worker starts in `observe` mode by default: explicit blocks pass through but
+each is recorded as a `permission.block_observed` activity event. Once the user
+has confirmed the block set is what they expect, an admin promotes the posture to `enforce` in
 the Ory Console (Agent Security). It is a permission on the project, read on
 every session, so the worker picks it up on its next run with no redeploy.
 
-On a hosted Ory project, grant `use` on each Activity name (`send_email`, …) in
-the Ory Console (Agent Security) before promoting the posture there — otherwise
-enforcement blocks every Activity. See {{REF_PERMISSIONS_ONBOARDING}}.
+Activities are allowed by default. Add `blockedSubjects` relations for Activity
+names that must not run, then review them before promoting the posture. See
+{{REF_PERMISSIONS_ONBOARDING}}.
 
-To exercise the deny path locally, kick the Workflow with an Activity name the
-local stack never granted, and watch it fail with the `Ory denied use of …`
-error in the Temporal Web UI.
+To exercise the deny path locally, add a `blockedSubjects` relation for an
+Activity name, kick the Workflow, and watch the explicit-block error in the
+Temporal Web UI.
 
 ## Step 7 — Beyond the dev server
 

package/assets/skills/permissions-onboarding/SKILL.md

@@ -1,195 +1,119 @@
 ---
 name: ory-permissions-onboarding
-description: Onboard a fresh install onto Ory Permissions for AI agent tool calls. Use when the user has just installed the Ory plugin and wants per-tool authorization enforced without first getting blocked by missing permissions. Covers connecting the plugin, reading coverage in observe mode, and what has to happen in the Ory Console (grants, blocks, enforce posture).
+description: Onboard native agent-tool authorization with default allow and explicit deny overrides. Covers connecting the plugin, reviewing allowed and blocked tools, writing blocks in the Ory Console, and promoting the project from observe to enforce. MCP and PermissionMode remain grant-based.
 ---
 
-# Onboard onto Ory Permissions for Agent Tool Calls
+# Onboard Ory Permissions for Agent Tool Calls
 
-You are helping a user move a freshly-installed Ory agent plugin from
-"disconnected" to "permissions are enforcing", without the common
-first-run failure mode of getting every tool call blocked because the
-project has no grants yet.
+Help the user connect Agent Security and roll out explicit native-tool blocks
+without treating missing grants as denials.
 
-**The plugin only reads permissions. It never writes them.** Everything
-that provisions the project — the permission model, per-tool grants,
-explicit blocks, and the observe/enforce posture — is done in the **Ory
-Console** (Agent Security) by someone with access to the project. That
-split is deliberate: it means installing and connecting a plugin needs
-nothing but project connection details and a public OAuth2 client id, with no
-workspace privilege and no project API key.
+**The plugin only reads permissions. It never writes them.** The permission
+model, native-tool blocks, MCP grants, and observe/enforce posture are managed
+in the **Ory Console** (Agent Security).
 
-Two things govern behavior:
+Native policy is simple:
 
-- **Whether Agent Security is connected** — it runs when a project URL,
-  canonical Agent Security origin, and public OAuth2 client id resolve. Existing
-  configurations fall back to the project URL when the canonical origin is
-  unset. Not connected means no login and no permission checks, with
-  tool calls recorded locally. Skills, commands, the local dev stack, and
-  the MCP server work either way — they don't need a project at all.
-- **`permissionMode`** — `observe` or `enforce`, **read from the Ory
-  project** on every session, and only meaningful once connected.
-  `observe` (the default) runs every check, records denials, and lets the
-  tool proceed. `enforce` blocks on deny. There is no local override — an
-  admin sets it in the Console.
+- `AgentTool` and `ShellTool` have no `users` relation.
+- Their `use` permit is `!blockedSubjects.includes(subject)`.
+- No matching block means allowed; a matching block means denied.
+- `observe` logs the block and proceeds; `enforce` vetoes the call.
+- MCP permissions and `PermissionMode#enforcedSubjects` remain grant-based.
 
-The journey: **install → connect → observe → grant in the Console →
-enforce in the Console.**
+## 1. Connect Agent Security
 
-## Step 1: Connect the plugin to the project
-
-A fresh install has the developer-experience half working and Agent
-Security not connected. Copy the connection details shown in the Ory Console
-under **Agent Security**:
+Copy the connection details shown in the Ory Console under **Agent Security**:
 
 ```sh
 {{NPX}} configure --project-url <URL> --agent-security-url <URL>
 ```
 
-- **project URL** — the project's SDK URL (`https://<slug>.projects.oryapis.com`).
-- **Agent Security URL** — the canonical broker origin (`https://agents.console.ory.com` in production).
-- **OAuth2 client id** — the project's public login client, provisioned
-  in the Console. The per-session user login needs it to complete its
-  PKCE browser flow.
-
-Then confirm what the plugin resolved:
+Then inspect the resolved configuration:
 
 ```sh
 {{NPX}} status
 ```
 
-What you want to see:
-
-- **Project URL**: a real Ory URL or your local dev gateway (not "NOT SET").
-- **OAuth2 Client**: the project's public login client (not "NOT SET").
-- **Agent Security**: connected. If it says "not connected", it names the
-  unresolved connection value.
-
-If the user doesn't have those values, they need them from whoever
-administers the project. Don't try to create the client from here — the
-plugin has no privilege to, by design.
+Confirm that Agent Security is connected and the public OAuth2 login client is
+resolved. The plugin needs no workspace privilege or project API key.
 
-## Step 2: Look at the current permission posture
+## 2. Review Native Tool Access
 
 ```sh
 {{NPX}} permissions
 ```
 
-This prints:
+The report shows:
 
-- The live **permission mode** (`observe` or `enforce`) and whether it
-  came from the project, a cached value, or the default.
-- The **subject** — the user identity permissions are checked against.
-- For each tool in this harness's built-in catalog, **allowed / denied /
-  blocked / errored**, from a real check against the project right now.
-- A one-line coverage summary for decomposed shell command words.
+- The live permission mode and its source.
+- The user subject being checked.
+- Each built-in native tool as `allowed`, `blocked`, or `errored`.
+- A compact allowed/blocked summary for decomposed shell command words.
 
-On a freshly-connected project you will usually see every tool reported
-as **denied** — no grants exist for this user yet. In observe mode that
-blocks nobody: tool calls run through, and you are seeing what *would*
-be blocked under enforce.
+A fresh project normally reports native tools as **allowed**. There is no grant
+coverage step and the local seed writes no baseline `AgentTool` or `ShellTool`
+grants.
 
-If status prints `Mode: enforce` while tools are denied, tool calls
-**are** being blocked right now. The fix is in the Console (grant the
-tools, or move the project back to observe) — not from the CLI.
+## 3. Add Explicit Blocks in the Console
 
-## Step 3: Run a real session in observe mode
+To block a native tool, write a `blockedSubjects` relation in the Ory Console:
 
-Observe mode is the discovery phase. Use the harness normally, then look
-at what was recorded:
-
-```sh
-{{NPX}} status          # summary + recent activity
-{{NPX}} watch           # live event, decision, and error view
+```text
+namespace: AgentTool
+object:    <tool name>          e.g. WebFetch
+relation:  blockedSubjects
+subject:   User:<id>
 ```
 
-Launch the harness with `ORY_AGENT_DEBUG=true` to include verbose diagnostics in
-the watched log and stderr. Denials appear as `permission.observe_deny` activity events (and
-`permission.block_observed` for an explicit block), with the tool name
-and the subject. That list is exactly what has to be granted before
-enforce is safe.
-
-## Step 4: Grant the tools in the Ory Console
+To block a command word reached through a shell tool:
 
-In the Ory Console → **Agent Security**, grant the subject `use` on the
-tools it needs. The grant shape the runtime checks is:
-
-```
-namespace: AgentTool           (or whatever ORY_PERMISSION_NAMESPACE is set to)
-object:    <tool name>          (e.g. Read, Bash, WebFetch)
-relation:  use
-subject:   User:<id>            (a SubjectSet — namespace `User`, object the user id)
+```text
+namespace: ShellTool
+object:    <command word>       e.g. curl
+relation:  blockedSubjects
+subject:   User:<id>
 ```
 
-Notes worth passing on to the user:
-
-- The subject is a **SubjectSet** (`User:<id>`), which is what the
-  Console's *Add relationship* dialog emits and exactly what the runtime
-  check uses. A bare subject id will not match.
-- Granting a **group** and putting users in it scales better than
-  per-user grants; the check follows subject-set expansion.
-- **Shell command words** are authorized separately in the `ShellTool`
-  namespace (`ShellTool:curl#use`, …) because a denied surface is
-  otherwise reachable through `bash -c "curl …"`.
-- **MCP server tools** are discovered dynamically per session, so they
-  are not in the built-in catalog and need granting as they come into
-  scope.
-
-Re-run `{{NPX}} permissions` afterwards to confirm coverage.
+Blocks can also target the project, an agent credential, an agent session, a
+sub-agent credential, or a sub-agent spawn. Group/SubjectSet expansion is
+supported. A native deny is always an explicit block, never a missing grant.
 
-## Step 5: Promote to enforce in the Console
+MCP is intentionally different: continue granting MCP server/tool access with
+its existing `users`/`use` and `invoke` relations.
 
-Once the tools the user actually needs report `allowed`, an admin flips
-the posture in the Console (Agent Security). The mode is a permission on
-the project, so it can be set **project-wide** — covering principals
-that don't exist yet — or **per principal** as an exception.
+## 4. Observe Before Enforcing
 
-Every session reads the live mode, so the change takes effect without
-reinstalling or reconfiguring anything. Confirm it landed:
+While the project is in `observe`, run normal sessions and inspect:
 
 ```sh
 {{NPX}} permissions
+{{NPX}} watch
 ```
 
-## Step 6: Verify a real session under enforce
+Matching blocks emit `permission.block_observed` but the tool still runs. Review
+those events, then promote the project or selected principals to `enforce` in
+the Ory Console. Every gate reads the project-controlled posture.
 
-Start a normal agent session and confirm:
+## 5. Verify Enforcement
 
-- **Allowed tools** invoke without complaint.
-- **Denied tools** are blocked with a clear "Ory: permission denied"
-  message naming the tool (or the shell command word).
-- The activity log shows `permission.check` events per tool call and
-  `tool.block` events for denials.
+Under `enforce`:
 
-If a tool is unexpectedly blocked, run `{{NPX}} permissions` to
-see whether it is `denied` (no grant) or `blocked` (an explicit
-deny-override), then fix it in the Console and re-test.
+- Tools without a matching block run normally.
+- Explicitly blocked tools produce a clear "explicitly blocked" message.
+- A blocked `ShellTool` word blocks the outer shell command and names the word.
+- Infrastructure failures retain the core fail-open behavior.
 
-## Explicit blocks (deny-override)
-
-Granting is additive. To express the opposite — a subject is **blocked**
-from a tool, beating any grant, including one inherited through a group —
-an admin writes a `blockedSubjects` relation in the Console. Ory evaluates it
-natively (the `use` permit is "granted AND not blocked"), so it holds
-no matter how the grant was reached.
-
-A block behaves like any other deny: under **observe** it is recorded (a
-`permission.block_observed` activity event) but the tool still runs; under
-**enforce** it blocks. `permissions` marks blocked tools so they
-are distinguishable from a plain missing grant at a glance.
+If a tool is unexpectedly blocked, use `{{NPX}} permissions` to identify the
+block and remove or narrow its `blockedSubjects` relation in the Console.
 
 ## Reference
 
 | Command | Effect |
 |---|---|
-| `{{NPX}} configure --project-url <URL> --agent-security-url <URL>` | Connect the plugin to the canonical Agent Security broker. |
-| `{{NPX}} configure --disconnect` | Turn sign-in and permission checks back off. Skills, commands, the local stack, and activity logging are unaffected. |
-| `{{NPX}} permissions` | Print the live mode + per-tool allowed/denied/blocked breakdown. Read-only. |
-| `{{NPX}} status` | Configuration, identities, permission coverage, recent activity. |
-
-Done in the **Ory Console** (Agent Security), not from the CLI: applying
-the permission model, granting `use` on tools, writing explicit blocks,
-and setting the observe/enforce posture.
-
-For deeper background on the authentication side of the flow (which
-identity is the subject, how the user gate resolves it), see
-{{REF_AUTH_SETUP}} and {{REF_LOGIN_FLOW}}.
+| `{{NPX}} configure --project-url <URL> --agent-security-url <URL>` | Connect Agent Security. |
+| `{{NPX}} configure --disconnect` | Disconnect sign-in and permission checks. |
+| `{{NPX}} permissions` | Print live mode plus native allowed/blocked state. Read-only. |
+| `{{NPX}} status` | Print configuration, identities, native tool access, and recent activity. |
+
+For authentication and subject-resolution details, see {{REF_AUTH_SETUP}} and
+{{REF_LOGIN_FLOW}}.

package/dist/adapters.js

@@ -366,7 +366,7 @@ async function decideTool(client, opts) {
     const label = (0, subject_js_1.subjectLabel)(subjectRef);
     const canBlock = opts.canBlock ?? true;
     const activityAttrs = gateActivityAttributes(opts);
-    const check = { namespace, object: opts.toolName, relation: "users", ...subjectRef };
+    const check = { namespace, object: opts.toolName, relation: "use", ...subjectRef };
     if (!(0, config_js_1.isSecurityConnected)()) {
         const outcome = {
             kind: "not_connected",

package/dist/bash-parser.js

@@ -172,6 +172,16 @@ function resolveCommandName(nameNode) {
             return basename(child.text);
     }
 }
+function commandNameIsAmbiguous(nameNode, name) {
+    const raw = nameNode.text;
+    if (!/[\\'"$]/.test(raw))
+        return false;
+    if (!name)
+        return true;
+    if (raw === `"${name}"` || raw === `'${name}'`)
+        return false;
+    return !raw.endsWith(`/${name}"`) && !raw.endsWith(`/${name}'`);
+}
 function argNodes(cmd) {
     return cmd.childrenForFieldName("argument").filter((n) => n !== null);
 }
@@ -271,7 +281,7 @@ function walk(node, pipeline, parser, state, depth, treeDepth) {
         }
         const pid = pipeline >= 0 ? pipeline : state.pipelineCounter++;
         const name = resolveCommandName(nameNode);
-        if (name === null)
+        if (name === null || commandNameIsAmbiguous(nameNode, name))
             state.tooComplex = true;
         const args = argNodes(node);
         state.commands.push({
@@ -361,6 +371,8 @@ async function extractShellCommands(command) {
     if (!tree)
         return { commands: [], tooComplex: true };
     const state = { commands: [], tooComplex: false, pipelineCounter: 0 };
+    if (command.includes("\\\n"))
+        state.tooComplex = true;
     if (tree.rootNode.hasError)
         state.tooComplex = true;
     // The walk must never throw out of this function — an uncaught error would

package/dist/build-info.json

@@ -1,9 +1,9 @@
 {
   "repo": "ory-agent-plugins",
-  "commit": "f803b3fe7be2cd6918652a082a7a4a3eb4ddab53",
-  "commitShort": "f803b3f",
+  "commit": "fc87fd73772d79007d1072c605ede76de42792ce",
+  "commitShort": "fc87fd7",
   "branch": "main",
-  "commitDate": "2026-08-30T11:50:10-07:00",
+  "commitDate": "2026-08-30T17:10:01-07:00",
   "dirty": false,
-  "builtAt": "2026-08-30T18:53:36.809Z"
+  "builtAt": "2026-08-31T00:13:34.583Z"
 }

package/dist/cli.js

@@ -125,7 +125,7 @@ function runConfigureCommand(binName, args) {
         console.log(`User subject ns:  ${resolved.userSubjectNamespace ?? "User (default)"} [${resolved.userSubjectNamespaceSource}]`);
         console.log("");
         if (resolved.security.connected) {
-            console.log("Sign-in and permission checks are running. Tool grants, explicit blocks,");
+            console.log("Sign-in and permission checks are running. Native-tool blocks, MCP grants,");
             console.log("and the observe/enforce posture are managed in the Ory Console (Agent Security).");
             console.log("");
             console.log("To disconnect (skills, commands, the local stack, and activity logging keep working):");

package/dist/contract-suite.js

@@ -200,9 +200,12 @@ function runHarnessContractSuite(adapter) {
                 else {
                     (0, vitest_1.expect)(blockEvents).toHaveLength(0);
                 }
-                // Observe-mode denies also emit the audit event; enforce must not.
+                // Native tools are default-allow, so a denied use check is an
+                // explicit block and receives the block-specific observe event.
                 const observeEvents = (0, testing_js_1.getActivityEvents)(client, "permission.observe_deny");
-                (0, vitest_1.expect)(observeEvents).toHaveLength(check === "denied" && mode === "observe" ? 1 : 0);
+                const blockObservedEvents = (0, testing_js_1.getActivityEvents)(client, "permission.block_observed");
+                (0, vitest_1.expect)(observeEvents).toHaveLength(0);
+                (0, vitest_1.expect)(blockObservedEvents).toHaveLength(check === "denied" && mode === "observe" ? 1 : 0);
             });
             (0, vitest_1.it)("records tool.invoke when an interactive tool proceeds", async () => {
                 process.env.ORY_INTERACTIVE_TOOLS = adapter.tool;

package/dist/local/manager.js

@@ -849,7 +849,7 @@ function printSeedResult(result) {
     console.log(`  User password:  ${result.user.password}`);
     console.log(`  User OAuth2:    ${result.user.client.clientId} (PKCE)`);
     console.log("");
-    console.log(`  Permissions: ${result.permissions.tuples} entries in '${result.permissions.namespace}' for ${result.permissions.subject}`);
+    console.log(`  Native tool grants: none (default allow; explicit blocks only)`);
     console.log("");
     console.log("To use with any Ory agent plugin, set these environment variables:");
     console.log("");

package/dist/local/seed.d.ts

@@ -53,7 +53,7 @@ export interface SeedResult {
         /** OAuth2 authorization_code+PKCE client for interactive logins. */
         client: SeededOAuth2Client;
     };
-    /** Permission tuples written against the user's subject. */
+    /** Native baseline permission tuples written against the user's subject (always zero). */
     permissions: {
         namespace: string;
         subject: string;

package/dist/local/seed.js

@@ -27,14 +27,11 @@ exports.USER_SUBJECT_NAMESPACE = exports.USER_CLIENT_ID = void 0;
 exports.seedLocalEnvironment = seedLocalEnvironment;
 const auth_js_1 = require("../auth.js");
 const branding_js_1 = require("../branding.js");
-const tool_catalog_js_1 = require("../tool-catalog.js");
 const subject_js_1 = require("../subject.js");
-const opl_js_1 = require("../opl.js");
 const configs_js_1 = require("./configs.js");
 const ports_js_1 = require("./ports.js");
 const health_js_1 = require("./health.js");
 const KRATOS_ADMIN = (0, ports_js_1.hostUrl)(configs_js_1.LOCAL_STACK_HOST, configs_js_1.KRATOS_ADMIN_PORT);
-const KETO_WRITE = (0, ports_js_1.hostUrl)(configs_js_1.LOCAL_STACK_HOST, configs_js_1.KETO_WRITE_PORT);
 const HYDRA_ADMIN = (0, ports_js_1.hostUrl)(configs_js_1.LOCAL_STACK_HOST, configs_js_1.HYDRA_ADMIN_PORT);
 const USER_EMAIL = "user@ory-local.dev";
 const USER_PASSWORD = "ory-user-local-dev-password!";
@@ -49,11 +46,6 @@ const USER_PASSWORD = "ory-user-local-dev-password!";
  * dragging the value out of the `local up` banner.
  */
 exports.USER_CLIENT_ID = branding_js_1.USER_LOGIN_CLIENT_ID;
-/**
- * Tools the explicit local-stack command seeds tuples for. Sourced from the
- * shared catalog so one seed covers every harness's built-in tool set.
- */
-const COMMON_TOOLS = tool_catalog_js_1.ALL_TOOLS;
 async function jsonFetch(url, opts = {}) {
     const res = await fetch(url, {
         ...opts,
@@ -94,44 +86,6 @@ async function seedIdentity(email, password, name) {
  * install config all address the user under the same namespace.
  */
 exports.USER_SUBJECT_NAMESPACE = subject_js_1.DEFAULT_USER_SUBJECT_NAMESPACE;
-/**
- * Write permission tuples granting the user identity access to all
- * common tools. The subject is written as a SubjectSet
- * `User:<userId>` (no relation) so the Console UI's *Add relationship*
- * dialog — which only emits SubjectSet subjects — can recreate the same
- * tuple by hand during the runbook walkthrough.
- */
-async function seedPermissions(userId, namespace, objects = COMMON_TOOLS) {
-    let created = 0;
-    for (const object of objects) {
-        try {
-            await jsonFetch(`${KETO_WRITE}/admin/relation-tuples`, {
-                method: "PUT",
-                body: JSON.stringify({
-                    namespace,
-                    object,
-                    relation: opl_js_1.RELATION_USERS,
-                    subject_set: {
-                        namespace: exports.USER_SUBJECT_NAMESPACE,
-                        object: userId,
-                        relation: "",
-                    },
-                }),
-            });
-            created++;
-        }
-        catch (err) {
-            const msg = err instanceof Error ? err.message : String(err);
-            if (!msg.includes("409")) {
-                process.stderr.write(`  Warning: failed to create permission for ${object}: ${msg}\n`);
-            }
-            else {
-                created++;
-            }
-        }
-    }
-    return created;
-}
 /**
  * Delete a Hydra OAuth2 client if it exists, then create it at a known
  * client_id (with a known secret, for a confidential client). We always
@@ -209,22 +163,10 @@ async function seedLocalEnvironment(namespace = "AgentTool") {
     process.stderr.write("  Creating user identity...\n");
     const userIdentity = await seedIdentity(USER_EMAIL, USER_PASSWORD, "Local User");
     process.stderr.write(`  User: ${userIdentity.id} (${userIdentity.email})\n`);
-    // 2. Permission tuples — written against the user's identity since the
-    //    user is the subject of permission checks in the plugin handlers.
-    //    Subject is a SubjectSet `User:<id>` so the Console UI can rewrite
-    //    the same tuple shape by hand during the runbook demo.
+    // 2. Native tools are allowed by default. Seed no AgentTool or ShellTool
+    //    baseline grants; local behavior must match hosted default-allow policy.
     const subjectLabel = `${exports.USER_SUBJECT_NAMESPACE}:${userIdentity.id}`;
-    process.stderr.write(`  Creating permissions for ${COMMON_TOOLS.length} tools...\n`);
-    const tupleCount = await seedPermissions(userIdentity.id, namespace);
-    process.stderr.write(`  Permissions: ${tupleCount} entries in '${namespace}' for ${subjectLabel}\n`);
-    // Shell-command sub-tools (issue #76): grant every catalog word in the
-    // ShellTool namespace so a launched harness can run `bash -c "curl …"`
-    // out of the box, and the enforce demo (revoke `ShellTool:curl#users`,
-    // watch it block) works without hand-writing tuples first.
-    const shellWords = (0, tool_catalog_js_1.getShellCommandCatalog)();
-    const shellNamespace = (0, tool_catalog_js_1.resolveShellCommandNamespace)();
-    const shellCount = await seedPermissions(userIdentity.id, shellNamespace, shellWords);
-    process.stderr.write(`  Shell commands: ${shellCount} entries in '${shellNamespace}' for ${subjectLabel}\n`);
+    process.stderr.write("  Native tools: allowed unless explicitly blocked (no baseline grants)\n");
     // 3. User OAuth2 client (PKCE) — pre-registered so the user gate's
     //    PKCE flow has somewhere to authenticate against. The agent's
     //    OAuth2 client is intentionally NOT pre-registered; the harness
@@ -253,6 +195,6 @@ async function seedLocalEnvironment(namespace = "AgentTool") {
     }
     return {
         user: { identity: userIdentity, password: USER_PASSWORD, client: userClient },
-        permissions: { namespace, subject: subjectLabel, tuples: tupleCount },
+        permissions: { namespace, subject: subjectLabel, tuples: 0 },
     };
 }

package/dist/opl.d.ts

@@ -1,19 +1,14 @@
 /**
  * Ory Permission Language (OPL) schema for the Agent Security permission model.
  *
- * Argus relies on more than relation-tuple *existence*: a subject may be granted
- * a tool and separately **blocked** from it, and the block must win. Keto
- * permission is otherwise purely existence-based (no path ⇒ no access, any path
- * ⇒ access), so the deny-override is modeled natively in OPL as a permit:
+ * Native agent and shell tools are allowed by default and may be explicitly
+ * blocked. The deny is modeled natively in OPL as a permit:
  *
- *     use = users.includes(subject) && !blockedSubjects.includes(subject)
+ *     use = !blockedSubjects.includes(subject)
  *
- * Keto evaluates the permit in a single check, so a `blockedSubjects` relation
- * beats a `users` grant no matter how the grant was reached (direct subject or
- * subject-set expansion). Argus always checks the **`use` permit** (see
- * `resolveCheckRelation`), so this model must be applied to the project for
- * checks to resolve; with nothing blocked, `use` resolves identically to a bare
- * `users` existence check, so grants alone allow.
+ * Argus always checks the **`use` permit**, so a missing block allows and a
+ * matching `blockedSubjects` relation denies. This model must be applied to the
+ * project for checks to resolve.
  *
  * ## Naming conventions
  *
@@ -194,8 +189,7 @@ export declare const PERMISSION_MODE_OBJECT = "mode";
  */
 export declare const PROJECT_POSTURE_OBJECT = "project";
 /**
- * The permit Argus checks: `users && !blockedSubjects`, evaluated natively by
- * Keto. A verb, as Keto's own `view` is — it names the question the gate asks.
+ * The native-tool permit Argus checks: `!blockedSubjects`, evaluated by Keto.
  */
 export declare const PERMIT_USE = "use";
 /**
@@ -236,9 +230,9 @@ export declare function renderOplImport(): string;
 /** Render a principal-namespace class (an empty `implements Namespace`). */
 export declare function renderPrincipalClass(name: string): string;
 /**
- * Render a tool-namespace class body: the `users` grant, the `blockedSubjects`
- * deny-override, and the `use` permit (`users && !blockedSubjects`) Argus
- * checks. The single definition of that class, used for both tool namespaces.
+ * Render a native tool-namespace class body: the `blockedSubjects` relation and
+ * the default-allow `use` permit Argus checks. The single definition is used for
+ * both AgentTool and ShellTool; MCP namespaces remain grant-based elsewhere.
  */
 export declare function renderToolNamespaceClass(namespace?: string): string;
 /**
@@ -248,8 +242,7 @@ export declare function renderToolNamespaceClass(namespace?: string): string;
  */
 export declare function renderDelegationNamespaceClass(namespace?: string): string;
 /**
- * Render the role class: the members of a shared role a project grants tools to.
- * One class, one relation — a role is a group of subjects and nothing else.
+ * Render the role class: a reusable group whose members can be blocked together.
  */
 export declare function renderAgentRoleNamespaceClass(namespace?: string): string;
 /** Render a harness/sub-agent type group whose members inherit posture. */

package/dist/opl.js

@@ -2,19 +2,14 @@
 /**
  * Ory Permission Language (OPL) schema for the Agent Security permission model.
  *
- * Argus relies on more than relation-tuple *existence*: a subject may be granted
- * a tool and separately **blocked** from it, and the block must win. Keto
- * permission is otherwise purely existence-based (no path ⇒ no access, any path
- * ⇒ access), so the deny-override is modeled natively in OPL as a permit:
+ * Native agent and shell tools are allowed by default and may be explicitly
+ * blocked. The deny is modeled natively in OPL as a permit:
  *
- *     use = users.includes(subject) && !blockedSubjects.includes(subject)
+ *     use = !blockedSubjects.includes(subject)
  *
- * Keto evaluates the permit in a single check, so a `blockedSubjects` relation
- * beats a `users` grant no matter how the grant was reached (direct subject or
- * subject-set expansion). Argus always checks the **`use` permit** (see
- * `resolveCheckRelation`), so this model must be applied to the project for
- * checks to resolve; with nothing blocked, `use` resolves identically to a bare
- * `users` existence check, so grants alone allow.
+ * Argus always checks the **`use` permit**, so a missing block allows and a
+ * matching `blockedSubjects` relation denies. This model must be applied to the
+ * project for checks to resolve.
  *
  * ## Naming conventions
  *
@@ -207,8 +202,7 @@ exports.PERMISSION_MODE_OBJECT = "mode";
  */
 exports.PROJECT_POSTURE_OBJECT = "project";
 /**
- * The permit Argus checks: `users && !blockedSubjects`, evaluated natively by
- * Keto. A verb, as Keto's own `view` is — it names the question the gate asks.
+ * The native-tool permit Argus checks: `!blockedSubjects`, evaluated by Keto.
  */
 exports.PERMIT_USE = "use";
 /** Conventional user namespace used for SubjectSet-addressed users (`User:<id>`). */
@@ -263,30 +257,25 @@ function renderPrincipalClass(name) {
     return `class ${name} implements Namespace {}`;
 }
 /**
- * Render a tool-namespace class body: the `users` grant, the `blockedSubjects`
- * deny-override, and the `use` permit (`users && !blockedSubjects`) Argus
- * checks. The single definition of that class, used for both tool namespaces.
+ * Render a native tool-namespace class body: the `blockedSubjects` relation and
+ * the default-allow `use` permit Argus checks. The single definition is used for
+ * both AgentTool and ShellTool; MCP namespaces remain grant-based elsewhere.
  */
 function renderToolNamespaceClass(namespace = exports.DEFAULT_NAMESPACE) {
     return `class ${namespace} implements Namespace {
   related: {
-    // Machine principals are grantable in their own right: \`${subject_js_1.AGENT_NAMESPACE}:<clientId>\` is
+    // Machine principals are blockable in their own right: \`${subject_js_1.AGENT_NAMESPACE}:<clientId>\` is
     // one session's registered agent credential and \`${subject_js_1.SUBAGENT_NAMESPACE}:<clientId>\` one
     // typed sub-agent credential in that session. Their narrower session- and spawn-scoped forms
     // (\`${subject_js_1.AGENT_NAMESPACE}:<clientId>|<session>\`, \`${subject_js_1.SUBAGENT_NAMESPACE}:<clientId>|<session>|<type>\`) are
     // members of the same namespaces, which is what lets a block name one run.
-    // A grant may also name the shared role, so one membership covers every
-    // tool in every tool namespace: \`@(${exports.AGENT_ROLE_NAMESPACE}:<role>#${exports.RELATION_MEMBERS})\`.
-    ${exports.RELATION_USERS}: (${USER_NAMESPACE} | ${subject_js_1.SESSION_NAMESPACE} | ${subject_js_1.AGENT_NAMESPACE} | ${subject_js_1.SUBAGENT_NAMESPACE} | SubjectSet<${exports.AGENT_ROLE_NAMESPACE}, "${exports.RELATION_MEMBERS}"> | SubjectSet<${namespace}, "${exports.RELATION_USERS}">)[]
+    // A block may also name the shared role's members.
     ${exports.RELATION_BLOCKED_SUBJECTS}: (${USER_NAMESPACE} | ${subject_js_1.SESSION_NAMESPACE} | ${subject_js_1.AGENT_NAMESPACE} | ${subject_js_1.SUBAGENT_NAMESPACE} | SubjectSet<${exports.AGENT_ROLE_NAMESPACE}, "${exports.RELATION_MEMBERS}"> | SubjectSet<${namespace}, "${exports.RELATION_BLOCKED_SUBJECTS}">)[]
   }
 
   permits = {
-    // Deny-override: any matching \`${exports.RELATION_BLOCKED_SUBJECTS}\` relation beats a
-    // \`${exports.RELATION_USERS}\` grant, regardless of how the grant was reached (direct or
-    // via a set).
+    // Native tools are allowed unless an explicit block matches.
     ${exports.PERMIT_USE}: (ctx: Context): boolean =>
-      this.related.${exports.RELATION_USERS}.includes(ctx.subject) &&
       !this.related.${exports.RELATION_BLOCKED_SUBJECTS}.includes(ctx.subject),
   }
 }`;
@@ -316,15 +305,13 @@ function renderDelegationNamespaceClass(namespace = exports.DELEGATION_NAMESPACE
 }`;
 }
 /**
- * Render the role class: the members of a shared role a project grants tools to.
- * One class, one relation — a role is a group of subjects and nothing else.
+ * Render the role class: a reusable group whose members can be blocked together.
  */
 function renderAgentRoleNamespaceClass(namespace = exports.AGENT_ROLE_NAMESPACE) {
     return `class ${namespace} implements Namespace {
   related: {
-    // The subjects that belong to the role. A tool grant names
-    // \`(${namespace}:<role>#${exports.RELATION_MEMBERS})\` as its subject, so adding a member grants
-    // every tool the role holds, in either tool namespace, from one relation.
+    // The subjects that belong to the role. A native-tool block can name
+    // \`(${namespace}:<role>#${exports.RELATION_MEMBERS})\` to block the group.
     ${exports.RELATION_MEMBERS}: (${USER_NAMESPACE} | ${subject_js_1.AGENT_NAMESPACE} | ${subject_js_1.SUBAGENT_NAMESPACE} | SubjectSet<${namespace}, "${exports.RELATION_MEMBERS}">)[]
   }
 }`;
@@ -408,20 +395,18 @@ function buildAgentSecurityOpl(namespace = exports.DEFAULT_NAMESPACE, shellNames
         "// that has no such relation, rather than storing a tuple that never matches.",
         ...exports.NODE_REFERENCE_NAMESPACES.map(renderPrincipalClass),
         "",
-        `// Harness tool objects (\`${namespace}:Bash\`). \`${exports.RELATION_USERS}\` is the set of subjects`,
-        `// granted the tool; \`${exports.RELATION_BLOCKED_SUBJECTS}\` is an explicit deny-override. The`,
-        `// \`${exports.PERMIT_USE}\` permit is the effective decision Argus checks: granted AND not`,
-        "// blocked.",
+        `// Harness tool objects (\`${namespace}:Bash\`). \`${exports.RELATION_BLOCKED_SUBJECTS}\` is an explicit`,
+        `// deny. The \`${exports.PERMIT_USE}\` permit is the effective decision Argus checks: allowed`,
+        "// unless blocked.",
         renderToolNamespaceClass(namespace),
         "",
         "// Shell command sub-tools (issue #76): each program/builtin word a shell",
         `// command runs is checked as \`${shellNamespace}:<word>#${exports.PERMIT_USE}\`, so a blocked`,
         '// binary (e.g. curl) can\'t be reached through `bash -c "curl …"`. Same',
-        "// grant / block / use model as the tool namespace above.",
+        "// default-allow / explicit-block model as the tool namespace above.",
         renderToolNamespaceClass(shellNamespace),
         "",
-        "// The shared role a project grants tools to, so an admin adds a member",
-        "// instead of re-granting every tool per identity.",
+        "// The shared role whose members can be blocked as a group.",
         renderAgentRoleNamespaceClass(),
         "",
         "// Delegation nodes: the current-state graph of who delegated to whom, written",

package/dist/permissions-cli.d.ts

@@ -10,8 +10,8 @@
  * v0.14, and the report is the same.)
  *
  * Everything that *writes* to the project is provisioned in the **Ory Console**
- * (Agent Security), not from the plugin: the permission model, the per-tool
- * grants, explicit blocks, and the observe/enforce posture. That is what lets a
+ * (Agent Security), not from the plugin: the permission model, explicit native
+ * blocks, MCP grants, and the observe/enforce posture. That is what lets a
  * plugin be installed with nothing but a project URL — the public OAuth2 client
  * id has a reserved default, with no workspace privilege, project API key, or admin write path. The
  * plugin is a read-only client of the project's permission state.

package/dist/permissions-cli.js

@@ -11,8 +11,8 @@
  * v0.14, and the report is the same.)
  *
  * Everything that *writes* to the project is provisioned in the **Ory Console**
- * (Agent Security), not from the plugin: the permission model, the per-tool
- * grants, explicit blocks, and the observe/enforce posture. That is what lets a
+ * (Agent Security), not from the plugin: the permission model, explicit native
+ * blocks, MCP grants, and the observe/enforce posture. That is what lets a
  * plugin be installed with nothing but a project URL — the public OAuth2 client
  * id has a reserved default, with no workspace privilege, project API key, or admin write path. The
  * plugin is a read-only client of the project's permission state.
@@ -26,7 +26,6 @@ const logger_js_1 = require("./logger.js");
 const agent_auth_js_1 = require("./agent-auth.js");
 const tool_catalog_js_1 = require("./tool-catalog.js");
 const subject_js_1 = require("./subject.js");
-const permissions_js_1 = require("./permissions.js");
 const opl_js_1 = require("./opl.js");
 function resolveNamespace() {
     return process.env.ORY_PERMISSION_NAMESPACE ?? "AgentTool";
@@ -79,7 +78,7 @@ function printPermissionsHelp(binName) {
     console.log("  observe  — Log an audit event and allow the tool through. The default.");
     console.log("  enforce  — Block the tool. The production posture.");
     console.log("");
-    console.log("The plugin only ever *reads* permissions. Tool grants, explicit blocks,");
+    console.log("The plugin only ever *reads* permissions. Native tool blocks, MCP grants,");
     console.log("the permission model, and the observe/enforce posture are all managed in");
     console.log("the Ory Console (Agent Security) by someone with access to the project.");
     console.log("");
@@ -97,8 +96,8 @@ function printProvisioningMovedToConsole(binName, attempted) {
     console.error("");
     console.error("Permissions are provisioned in the Ory Console (Agent Security):");
     console.error("  - the permission model applied to the project");
-    console.error("  - per-tool grants for a user, agent, or group");
-    console.error("  - explicit blocks (a deny that beats any grant)");
+    console.error("  - explicit native-tool blocks for a user, agent, or group");
+    console.error("  - MCP grants");
     console.error("  - the observe / enforce posture, project-wide or per principal");
     console.error("");
     console.error("The plugin reads that state and enforces it. To see what it resolves:");
@@ -119,7 +118,7 @@ async function runPermissionsStatus(binName, harness) {
     console.log("");
     if (!resolved.security.connected) {
         console.log("Ory Agent Security is not connected, so no permission checks run and there");
-        console.log("is no coverage to report. The rest of the plugin is unaffected.");
+        console.log("is no native tool access to report. The rest of the plugin is unaffected.");
         console.log("");
         console.log(`Connect with: ${binName} configure --project-url <URL>`);
         console.log("The project URL comes from the Ory Console (Agent Security).");
@@ -157,7 +156,6 @@ async function runPermissionsStatus(binName, harness) {
     const results = await probeCatalog(client, catalog, namespace, subject);
     const allowed = results.filter((r) => r.error === undefined && r.allowed).length;
     const blocked = results.filter((r) => r.blocked).length;
-    const denied = results.filter((r) => r.error === undefined && !r.allowed && !r.blocked).length;
     const errored = results.filter((r) => r.error !== undefined).length;
     const widest = Math.max(...catalog.map((t) => t.length), 4);
     console.log(`  ${"Tool".padEnd(widest)}  Status`);
@@ -167,53 +165,38 @@ async function runPermissionsStatus(binName, harness) {
             ? `error (${r.error})`
             : r.blocked
                 ? "blocked"
-                : r.allowed
-                    ? "allowed"
-                    : "denied";
+                : "allowed";
         console.log(`  ${r.tool.padEnd(widest)}  ${status}`);
     }
     console.log("");
-    console.log(`Summary: ${allowed} allowed, ${denied} denied, ${blocked} blocked, ${errored} errored.`);
+    console.log(`Summary: ${allowed} allowed, ${blocked} blocked, ${errored} errored.`);
     // Shell sub-tools (issue #76): a compact count rather than 100+ rows.
-    let shellDenied = 0;
+    let shellBlocked = 0;
     if ((0, tool_catalog_js_1.getShellToolCatalog)(harness).length > 0) {
         const shellNamespace = (0, tool_catalog_js_1.resolveShellCommandNamespace)();
         const shellWords = (0, tool_catalog_js_1.getShellCommandCatalog)();
         const shellResults = await probeCatalog(client, shellWords, shellNamespace, subject);
         const sAllowed = shellResults.filter((r) => r.allowed).length;
-        shellDenied = shellResults.filter((r) => r.error === undefined && !r.allowed).length;
+        shellBlocked = shellResults.filter((r) => r.blocked).length;
         const sErrored = shellResults.filter((r) => r.error !== undefined).length;
-        console.log(`Shell commands (${shellNamespace}): ${sAllowed} allowed, ${shellDenied} denied, ` +
+        console.log(`Shell commands (${shellNamespace}): ${sAllowed} allowed, ${shellBlocked} blocked, ` +
             `${sErrored} errored of ${shellWords.length}.`);
     }
-    if (denied > 0 || shellDenied > 0) {
-        console.log("");
-        console.log("Denied tools have no grant for this subject. Grant them in the Ory");
-        console.log("Console (Agent Security) — the plugin cannot write permissions.");
-    }
     if (blocked > 0) {
         console.log("");
-        console.log("'blocked' tools carry an explicit block that overrides any grant.");
+        console.log("'blocked' tools carry an explicit native-tool block.");
         console.log("Remove it in the Ory Console (Agent Security).");
     }
     return 0;
 }
 async function probeCatalog(client, catalog, namespace, subject) {
-    // Evaluate the effective `use` permit, exactly as the runtime gate does.
-    const relation = (0, permissions_js_1.resolveCheckRelation)("users");
+    // Evaluate the default-allow `use` permit, exactly as the runtime gate does.
+    const relation = opl_js_1.PERMIT_USE;
     const rows = [];
     for (const tool of catalog) {
         try {
             const result = await client.checkPermission({ namespace, object: tool, relation, ...subject }, { activityAttributes: { toolName: tool, source: "permissions_status" } });
-            let blocked = false;
-            if (!result.allowed) {
-                // Distinguish an explicit block from a plain missing grant.
-                blocked = await client
-                    .checkPermission({ namespace, object: tool, relation: opl_js_1.RELATION_BLOCKED_SUBJECTS, ...subject }, { activityAttributes: { toolName: tool, source: "permissions_status_block" } })
-                    .then((r) => r.allowed)
-                    .catch(() => false);
-            }
-            rows.push({ tool, allowed: result.allowed, blocked });
+            rows.push({ tool, allowed: result.allowed, blocked: !result.allowed });
         }
         catch (err) {
             const ory = err;

package/dist/permissions.d.ts

@@ -34,10 +34,10 @@ import type { OryError, OryErrorCode, PermissionCheck, PermissionResult } from "
  * Why a permission check came back denied, once the block-aware OPL schema is
  * in play:
  *
- *   - `not_granted` — the subject simply has no `use` grant on the object
- *     (the legacy "deny by absence" case).
- *   - `explicit_block` — a `blocked` relation matched the subject, so the
- *     `access` permit's deny-override fired even if a `use` grant exists.
+ *   - `not_granted` — compatibility for grant-based checks outside native
+ *     AgentTool/ShellTool policy (notably MCP).
+ *   - `explicit_block` — a native `use` permit denied because a
+ *     `blockedSubjects` relation matched.
  *
  * Threaded onto the decision's activity attributes and into the observe-mode
  * audit event so "explicitly blocked" is distinguishable from "never granted"
@@ -46,12 +46,9 @@ import type { OryError, OryErrorCode, PermissionCheck, PermissionResult } from "
  */
 export type BlockReason = "not_granted" | "explicit_block";
 /**
- * Map the logical grant relation a caller passes (`use`) onto the relation or
- * permit Argus actually checks. A `use` check always routes through the
- * block-aware `access` permit (`use && !blocked`), so an explicit block is
- * always respected — the permission model must therefore be applied to the
- * project (done in the Ory Console, Agent Security) for checks to resolve. Any
- * other relation passes through unchanged.
+ * Compatibility shim for callers that still pass the former native `users`
+ * relation. Native adapters now pass `use` directly; mapping `users` preserves
+ * the public helper contract without reintroducing grant-based native checks.
  */
 export declare function resolveCheckRelation(relation: string): string;
 /**

package/dist/permissions.js

@@ -42,12 +42,9 @@ const opl_js_1 = require("./opl.js");
 const subject_js_1 = require("./subject.js");
 const tool_catalog_js_1 = require("./tool-catalog.js");
 /**
- * Map the logical grant relation a caller passes (`use`) onto the relation or
- * permit Argus actually checks. A `use` check always routes through the
- * block-aware `access` permit (`use && !blocked`), so an explicit block is
- * always respected — the permission model must therefore be applied to the
- * project (done in the Ory Console, Agent Security) for checks to resolve. Any
- * other relation passes through unchanged.
+ * Compatibility shim for callers that still pass the former native `users`
+ * relation. Native adapters now pass `use` directly; mapping `users` preserves
+ * the public helper contract without reintroducing grant-based native checks.
  */
 function resolveCheckRelation(relation) {
     return relation === opl_js_1.RELATION_USERS ? opl_js_1.PERMIT_USE : relation;
@@ -428,10 +425,7 @@ async function decomposeAndCheck(client, args) {
         const results = [];
         for (let start = 0; start < words.length; start += batchSize) {
             const chunk = words.slice(start, start + batchSize);
-            // Route each word through the block-aware `access` permit (like the
-            // top-level check), so an explicit `ShellTool:<word>#blocked` overrides
-            // a `use` grant. With no block present, `access` == bare `use`.
-            const wordRelation = resolveCheckRelation("users");
+            const wordRelation = opl_js_1.PERMIT_USE;
             const checks = chunk.map((word) => ({
                 namespace,
                 object: word,
@@ -482,7 +476,7 @@ async function decomposeAndCheck(client, args) {
             const decision = applyPermissionMode(client, blocked ? false : allowed, {
                 namespace,
                 object: word,
-                relation: blocked ? opl_js_1.RELATION_BLOCKED_SUBJECTS : opl_js_1.RELATION_USERS,
+                relation: blocked ? opl_js_1.RELATION_BLOCKED_SUBJECTS : opl_js_1.PERMIT_USE,
                 subjectId: blocked?.subject ?? subject.subjectId,
                 subjectSet: blocked ? undefined : subject.subjectSet,
                 activityAttributes: {
@@ -494,7 +488,7 @@ async function decomposeAndCheck(client, args) {
                     } : {}),
                 },
                 modeOverride: args.modeOverride,
-                blockReason: blocked ? "explicit_block" : undefined,
+                blockReason: blocked || !allowed ? "explicit_block" : undefined,
             });
             if (decision.kind === "deny") {
                 deniedWords.push(word);
@@ -510,17 +504,9 @@ async function decomposeAndCheck(client, args) {
     const primaryBlock = primaryBlockedWord ? matchedBlocks.get(primaryBlockedWord) : undefined;
     // Aggregate. Enforce: any denied word blocks. Observe: pass through.
     if (deniedWords.length > 0) {
-        // Disambiguate an explicit block from a plain missing grant on the first
-        // denied word, so the deny event and denial message say "explicitly blocked".
+        // A native `use` deny can only be an explicit block.
         const primaryWord = primaryBlockedWord ?? deniedWords[0];
-        const blockReason = primaryBlock
-            ? "explicit_block"
-            : await probeBlockReason(client, {
-                namespace,
-                object: primaryWord,
-                relation: opl_js_1.RELATION_USERS,
-                ...subject,
-            });
+        const blockReason = "explicit_block";
         return {
             kind: "deny",
             result: {
@@ -533,7 +519,7 @@ async function decomposeAndCheck(client, args) {
                         relation: opl_js_1.RELATION_BLOCKED_SUBJECTS,
                         subjectId: primaryBlock.subject,
                     }
-                    : { namespace, object: primaryWord, relation: opl_js_1.RELATION_USERS, ...subject },
+                    : { namespace, object: primaryWord, relation: opl_js_1.PERMIT_USE, ...subject },
             },
             mode: "enforce",
             activityAttributes: {
@@ -588,8 +574,8 @@ async function checkAndDecide(client, check, opts = {}) {
     const resolved = (0, config_js_1.resolveConfig)();
     const mode = opts.modeOverride ?? resolved.permissionMode;
     const activityAttributes = buildDecisionAttributes(mode, check.subjectId, check.subjectSet);
-    // Route a `use` grant check through the block-aware `access` permit so
-    // explicit blocks are always respected.
+    // Native adapters pass `use`; `resolveCheckRelation` keeps older public
+    // callers that pass `users` on the same default-allow permit.
     const effectiveCheck = {
         ...check,
         relation: resolveCheckRelation(check.relation),
@@ -624,11 +610,13 @@ async function checkAndDecide(client, check, opts = {}) {
     // Report the decision against the caller's original check (relation `use`),
     // not the internal permit rewrite, so callers see the coordinates they passed.
     result = { ...result, check };
-    // On a deny, disambiguate "explicitly blocked" from "never granted" so the
-    // audit trail and denial messaging can tell them apart. Best-effort.
+    // A deny from the native `use` permit is necessarily an explicit block.
+    // Retain the diagnostic probe only for other grant-based public checks.
     const blockReason = result.allowed
         ? undefined
-        : await probeBlockReason(client, check);
+        : effectiveCheck.relation === opl_js_1.PERMIT_USE
+            ? "explicit_block"
+            : await probeBlockReason(client, check);
     const inner = applyPermissionMode(client, result.allowed, {
         namespace: check.namespace,
         object: check.object,

package/dist/post-install.d.ts

@@ -16,7 +16,7 @@
  * plugin logs activity locally and gates nothing. Nothing else changes either way.
  *
  * Everything *else* an Ory project needs to serve Agent Security — the login
- * OAuth2 client, the permission model, the per-tool grants, explicit blocks,
+ * OAuth2 client, the permission model, native-tool blocks, MCP grants,
  * and the observe/enforce posture — is provisioned in the **Ory Console**
  * (Agent Security), by someone with access to the project. The plugin never
  * writes project configuration, which is why installing it needs only a

package/dist/post-install.js

@@ -17,7 +17,7 @@
  * plugin logs activity locally and gates nothing. Nothing else changes either way.
  *
  * Everything *else* an Ory project needs to serve Agent Security — the login
- * OAuth2 client, the permission model, the per-tool grants, explicit blocks,
+ * OAuth2 client, the permission model, native-tool blocks, MCP grants,
  * and the observe/enforce posture — is provisioned in the **Ory Console**
  * (Agent Security), by someone with access to the project. The plugin never
  * writes project configuration, which is why installing it needs only a
@@ -112,7 +112,7 @@ async function runPostInstall(binName, _harness, args = []) {
     if (security.connected) {
         ui.success("Ory Agent Security is connected.");
         ui.hint("Sign-in and permission checks run on the next session.");
-        ui.hint("Tool grants, explicit blocks, and the observe/enforce posture are managed in the Ory Console (Agent Security).");
+        ui.hint("Native-tool blocks, MCP grants, and the observe/enforce posture are managed in the Ory Console (Agent Security).");
         ui.hint(`Inspect what this machine resolves with \`${binName} permissions status\`.`);
     }
     else {

package/dist/setup.js

@@ -441,7 +441,7 @@ function printConfiguredNextStepsNow(harnessName, uninstallCmd, opts) {
     else {
         ui.hint("It starts in observe mode: every tool call is checked, but nothing is blocked yet.");
         ui.blank();
-        ui.bullet("1. See what's happening — config and permission coverage:");
+        ui.bullet("1. See what's happening — config and native tool access:");
         ui.command(`${npx} status`);
         ui.blank();
         ui.bullet("2. Turn on enforcement once the activity log looks right:");

package/dist/status-cli.d.ts

@@ -20,7 +20,7 @@ export declare function printAgentIdentitySection(harness: string): void;
 export declare function printSubAgentIdentitiesSection(harness: string): void;
 /**
  * Render the "Permissions" block: the deny posture, the namespace, and the
- * coverage of the harness's built-in tool catalog.
+ * allowed/blocked state of the harness's built-in tool catalog.
  *
  * The network probe runs only when a project URL is configured *and* a user
  * identity is available (cached PKCE tokens or `ORY_USER_SUBJECT_ID`). When it

package/dist/status-cli.js

@@ -161,7 +161,7 @@ function printSubAgentIdentitiesSection(harness) {
 }
 /**
  * Render the "Permissions" block: the deny posture, the namespace, and the
- * coverage of the harness's built-in tool catalog.
+ * allowed/blocked state of the harness's built-in tool catalog.
  *
  * The network probe runs only when a project URL is configured *and* a user
  * identity is available (cached PKCE tokens or `ORY_USER_SUBJECT_ID`). When it
@@ -207,32 +207,32 @@ async function printPermissionsSection(binName, harness) {
     if (!probe) {
         return printNoCoverage(cachedMode, namespace, "unavailable (no user identity could be resolved)");
     }
-    const { total, allowed, denied, errored } = probe;
+    const { total, allowed, blocked, errored } = probe;
     console.log(`  Mode:        ${probe.mode}${formatModeSuffix(probe.modeSource)}`);
     console.log(`  Namespace:   ${namespace}`);
     console.log(`  Subject:     ${probe.subject}`);
-    if (errored > 0 && allowed === 0 && denied === 0) {
-        console.log(`  Coverage:    probe failed (${probe.errorCode ?? "unknown"})`);
+    if (errored > 0 && allowed === 0 && blocked === 0) {
+        console.log(`  Tool access: probe failed (${probe.errorCode ?? "unknown"})`);
         return;
     }
     const status = allowed === total
-        ? `fully granted (${allowed}/${total} built-in tools)`
+        ? `all allowed (${allowed}/${total} built-in tools)`
         : allowed === 0
-            ? `no grants (0/${total} built-in tools)`
-            : `partial (${allowed}/${total} built-in tools allowed)`;
-    console.log(`  Coverage:    ${status}`);
-    if (denied > 0) {
-        console.log("               grant the missing tools in the Ory Console (Agent Security)");
+            ? `all blocked (${blocked}/${total} built-in tools)`
+            : `${allowed} allowed, ${blocked} blocked of ${total} built-in tools`;
+    console.log(`  Tool access: ${status}`);
+    if (blocked > 0) {
+        console.log("               remove unwanted blocks in the Ory Console (Agent Security)");
     }
     else if (errored > 0) {
         console.log(`               ${errored} probe error(s) — run "${(0, cli_invocation_js_1.oryNpx)(binName)} permissions" for details`);
     }
 }
-/** The Mode / Namespace / Coverage lines for every path that can't probe. */
+/** The Mode / Namespace / Tool access lines for every path that can't probe. */
 function printNoCoverage(mode, namespace, coverage) {
     console.log(`  Mode:        ${mode}`);
     console.log(`  Namespace:   ${namespace}`);
-    console.log(`  Coverage:    ${coverage}`);
+    console.log(`  Tool access: ${coverage}`);
 }
 function isUserTokenUsable() {
     const tokens = (0, auth_store_js_1.loadTokens)();

package/dist/status-data.d.ts

@@ -16,6 +16,8 @@ import { type StatusSystemSection } from "./status-system.js";
 export interface PermissionsCoverage {
     total: number;
     allowed: number;
+    blocked: number;
+    /** @deprecated Native false results are explicit blocks; use `blocked`. */
     denied: number;
     errored: number;
     errorCode?: string;
@@ -32,14 +34,13 @@ export interface PermissionsCoverage {
 }
 /**
  * Probe the harness's built-in tool catalog against Ory, returning how many
- * tools the resolved user subject is allowed / denied / errored on, plus the
+ * tools the resolved user subject is allowed / blocked / errored on, plus the
  * live permission mode and the subject that was checked. Returns undefined when
  * a probe can't run (no project URL, empty catalog, no user identity). Never
  * throws.
  *
- * Checks route through {@link resolveCheckRelation}, i.e. the `access` permit —
- * the same relation the runtime gate evaluates — so a tool carrying an explicit
- * block is reported as denied here too, exactly as a tool call would be.
+ * Checks use the same default-allow `use` permit as the runtime gate. A false
+ * result therefore means an explicit block, not missing grant coverage.
  */
 export declare function probePermissionsCoverage(harness: string): Promise<PermissionsCoverage | undefined>;
 export interface StatusConfigSection {
@@ -141,7 +142,9 @@ export interface StatusSubAgentSection {
 }
 export type PermissionsCoverageStatus = 
 /** Agent Security isn't connected — no project URL and/or OAuth2 client id. */
-"not_connected" | "no_catalog" | "no_user" | "fully_granted" | "partial" | "no_grants" | "probe_failed";
+"not_connected" | "no_catalog" | "no_user" | "fully_allowed" | "partially_blocked" | "fully_blocked"
+/** @deprecated Pre-default-allow status names retained for API compatibility. */
+ | "fully_granted" | "partial" | "no_grants" | "probe_failed";
 export interface StatusPermissionsSection {
     mode: "observe" | "enforce";
     /** Where `mode` came from: a live project read, the local cache, or the default. */

package/dist/status-data.js

@@ -50,7 +50,6 @@ exports.collectStatusReport = collectStatusReport;
  */
 const config_js_1 = require("./config.js");
 const permission_mode_js_1 = require("./permission-mode.js");
-const permissions_js_1 = require("./permissions.js");
 const auth_store_js_1 = require("./auth-store.js");
 const agent_auth_js_1 = require("./agent-auth.js");
 const subject_js_1 = require("./subject.js");
@@ -69,14 +68,13 @@ function resolveNamespace() {
 }
 /**
  * Probe the harness's built-in tool catalog against Ory, returning how many
- * tools the resolved user subject is allowed / denied / errored on, plus the
+ * tools the resolved user subject is allowed / blocked / errored on, plus the
  * live permission mode and the subject that was checked. Returns undefined when
  * a probe can't run (no project URL, empty catalog, no user identity). Never
  * throws.
  *
- * Checks route through {@link resolveCheckRelation}, i.e. the `access` permit —
- * the same relation the runtime gate evaluates — so a tool carrying an explicit
- * block is reported as denied here too, exactly as a tool call would be.
+ * Checks use the same default-allow `use` permit as the runtime gate. A false
+ * result therefore means an explicit block, not missing grant coverage.
  */
 async function probePermissionsCoverage(harness) {
     const resolved = (0, config_js_1.resolveConfig)();
@@ -106,10 +104,11 @@ async function probePermissionsCoverage(harness) {
         additionalSubjects: agentSubject ? [{ scope: "agent", subject: agentSubject }] : [],
     });
     const namespace = resolveNamespace();
-    const relation = (0, permissions_js_1.resolveCheckRelation)("users");
+    const relation = opl_js_1.PERMIT_USE;
     const result = {
         total: catalog.length,
         allowed: 0,
+        blocked: 0,
         denied: 0,
         errored: 0,
         mode: live.mode,
@@ -124,8 +123,10 @@ async function probePermissionsCoverage(harness) {
             });
             if (probe.allowed)
                 result.allowed++;
-            else
+            else {
+                result.blocked++;
                 result.denied++;
+            }
         }
         catch (err) {
             const ory = err;
@@ -274,14 +275,14 @@ async function collectPermissions(harness) {
         return { ...base, coverageStatus: "no_user" };
     // The probe read the mode live; prefer it over the cached config value.
     const withMode = { ...base, mode: coverage.mode, modeSource: coverage.modeSource };
-    if (coverage.errored > 0 && coverage.allowed === 0 && coverage.denied === 0) {
+    if (coverage.errored > 0 && coverage.allowed === 0 && coverage.blocked === 0) {
         return { ...withMode, coverageStatus: "probe_failed", coverage };
     }
     const status = coverage.allowed === coverage.total
-        ? "fully_granted"
+        ? "fully_allowed"
         : coverage.allowed === 0
-            ? "no_grants"
-            : "partial";
+            ? "fully_blocked"
+            : "partially_blocked";
     return { ...withMode, coverageStatus: status, coverage };
 }
 function isUserTokenUsable() {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ory/argus",
-  "version": "1.0.1",
+  "version": "1.1.0",
   "description": "Ory Argus: the core API for building authentication, authorization, and audit into AI agent harness plugins, extensions, and custom integrations",
   "license": "Apache-2.0",
   "homepage": "https://ory.com",