What you do with it

The package is a checkpoint your agents call before a write, export, deploy, or agent creation. It does not scan office Wi-Fi, a VPN, or the public internet for unknown agents. Agents that never ask Shield stay invisible to it.

Same four steps on a laptop or in a company:

1. Set up a console (local or hosted).
2. Register each agent with a name.
3. Wrap the tools that write, export, deploy, or create another agent, so Shield checks them first.
4. If the answer is Hold, the action waits in Approvals until a person accepts or rejects it. The agent never sees the secret.

Allow lets the call run and logs it. Deny stops the call. The Policy page cards are a dry run of that question. They are not a company-wide on/off switch.

After a local install

1. Run kya start (init + wire MCP + open the activity report), then restart your editor once.
2. Call a tool once through the gate. The receipt updates live.
3. Optional: point KYA_BASE_URL at a live console and open Approvals for Hold requests.

--offline is a sample. It is not the production gate. Until a real tool asks Shield, the console looks empty or tutorial-only.

Install commands · Solo free local

After a company install

1. One shared console (hosted or self-hosted). That is the agent list and the Approvals queue.
2. Issue API keys per team or per runtime. Do not reuse a laptop key in production.
3. Tag laptops host=ide and production bots host=runtime.
4. Wrap the writes that matter. Unwrapped tools are not governed.
5. Operators work in Approvals, Sessions, and Agents. Kill or revoke an agent by name. Limit a live session that should lose Deploy.

Hosted console · Self-host

Holds that mean something

A Hold is not a casual "Allow assistant to continue?" prompt. You see the tool, the agent, and the scope. The write stays blocked until you approve. Every check and every Hold is recorded on the trail.

What it sees

Location does not matter. Office LAN and a vendor cloud use the same rules. The split that matters is building versus production.

Covered: any registered agent that asks Shield first. That can be an internal bot, a contractor laptop, a SaaS runtime, or a marketplace MCP server.

Not covered: agents that never call Shield, raw network traffic, and personal ChatGPT with no Shield connector. Shield does not scan networks to find unknown agents. An agent created by another agent shows only if the creating agent is registered.

Two environments

One policy decision point for building and production:

Host	Intent
host=ide	Build, evaluate, observe, dry-run in IDE / CLI
host=runtime	Production agents serving real work

Same identity, policy, approval, and trail on both hosts.

Your own tools

• Govern any stable toolId. You do not need a prebuilt adapter module.
• Verdicts: ALLOW, DENY, or REQUIRE_APPROVE.
• Protocol-first install: MCP, OpenAPI / HTTP, generic webhooks.
• Industry packs (like the disputes pack) are optional add-ons.

Six layers

Layer	Capability
L1	Agent identity and lifecycle (registry, version hash, kill/revoke)
L2 to L3	Sign-in, authorization, and delegation bounds
L4	Runtime policy: ALLOW, DENY, or REQUIRE_APPROVE
L5	Behavior monitoring and kill switch
L6	Evidence graph, event log, export

Create is a tool

Registering an agent goes through the same policy check as any other write. A person can create a first agent under the workspace create mode: allow and record, emergency override with a reason, or require approval. When one agent creates another, that creation is always checked. Without approval, there is no child agent.

Sessions can be limited

Clearance is what a session may still do: Read, Build, or Deploy. HIGH risk follows the workspace limit mode: an operator limits the session, it drops to Build automatically, or it needs approval. Limiting never kills the agent. Restoring is a separate operator action.

Passports are signed

The v1 JSON passport stays for old clients. v2 is a signed claim (shield-kya-agent-passport-v2 and shield-kya-session-claim-v1) using the console's signing key. Verify returns valid, expired, revoked, or bad signature. The claim is a signature from your console, not a public certificate.

Fail closed defaults (hosted workspaces)

The hosted console enforces and fails closed (preview). The open source CLI is advisory and fails open on internal error, but its local hook still blocks the never-list and the guard pack. Policy enforcement lives on the MCP gate path and on the hosted service.

• If approval is required and missing, the side effect is denied.
• Policy DENY blocks the action. There is no silent bypass.
• Session risk may only raise severity. It never auto-allows a high-stakes action.
• Personal data is redacted before model calls.

Modules

• Core: registry, policy, approvals, personal-data redaction, trail.
• Observe: session reporting and session risk (optional).
• Audit: an evidence graph you can export for auditors (optional).
• Edge: optional Gatekeeper only after Shield has approved. Shield still decides policy.

What Shield owns

Identity, policy, human approval, personal data redaction, and the event trail stay here. Domain workflows and vendor connectors do not own approval or the event log.

Public source: The-Pixel-Boys/shield-kya. Same mark as the header.

Install Getting started Docs Use cases