@ory/argus 1.0.0 → 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": "6f11a1695f60ec11e7905c6a73f8683235c5e4df",
-  "commitShort": "6f11a16",
+  "commit": "fc87fd73772d79007d1072c605ede76de42792ce",
+  "commitShort": "fc87fd7",
   "branch": "main",
-  "commitDate": "2026-08-29T19:17:15-07:00",
+  "commitDate": "2026-08-30T17:10:01-07:00",
   "dirty": false,
-  "builtAt": "2026-08-30T02:20:53.108Z"
+  "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. */