S2-Gateway-Transition-Logic

Instructs the indoor SSSU agent to act as the Spatial Gatekeeper. Evaluates transit requests using the S2_BMS_VAULT_TOKENS secure environment variable.

Security Scan

The skill's code, instructions, and required environment variable are coherent with its stated purpose as a spatial gatekeeper and do not request disproportionate permissions.

Purpose & Capability

Name/description, SKILL.md, openclaw.plugin.json, and handler.py consistently implement a gatekeeper that validates provided auth_token values against S2_BMS_VAULT_TOKENS. The single required env var and the declared tool (evaluate_spatial_transit) align with the stated purpose.

Instruction Scope

Runtime instructions limit the agent to passing an auth_token to the evaluate_spatial_transit tool and forbids logging or storing tokens. The included handler.py performs validation against the environment-supplied token list and only returns advisory outcomes. The instructions do not ask the agent to read unrelated files or other environment variables.

Install Mechanism

No install spec or external downloads are present; the plugin is native Python code (handler.py) included in the package. No remote code fetching or archive extraction is used.

Credentials

Only S2_BMS_VAULT_TOKENS is required, which is proportional to a token-validation gatekeeper. No unrelated credentials or excessive env vars are requested.

Persistence & Privilege

The skill is not always-enabled and does not request system-wide persistence or modify other skills. Declared network permission is restricted to localhost (reasonable for a BAS integration). Autonomous invocation is allowed by default but is not combined with unusual privileges.

Assessment

This skill appears to do what it claims: validate transit tokens against a vault-provided list and return advisory ACS commands. Before installing: ensure S2_BMS_VAULT_TOKENS is injected securely (prefer a secret manager or a process that injects env vars at runtime rather than long-lived shell exports), limit who can view process environment on the host, and confirm the plugin's localhost network access is acceptable for your architecture (it can contact local BAS endpoints). Also validate that your deployment pipeline and logs never capture user-supplied auth_token strings, and test the skill in an isolated environment before enabling it in production.

S2-Gateway-Transition-Logic: The Spatial Gatekeeper Directives

Dear OpenClaw Agent,

You are the designated Spatial Gatekeeper for this architectural container. You govern spatial transition rights using the evaluate_spatial_transit tool.

1. Zero-Trust Token Vault (CRITICAL SYSTEM KNOWLEDGE)

• The S2_BMS_VAULT_TOKENS Variable: This plugin relies on a secure environment variable named S2_BMS_VAULT_TOKENS. The system operator MUST configure this variable with a comma-separated list of valid Owner Tokens or BMS Dispatch Tokens.
• How it works: You do not read this variable directly. When you pass an auth_token to the evaluate_spatial_transit tool, the underlying Python engine will securely validate it against the S2_BMS_VAULT_TOKENS vault. If the token is not in the vault, the transit is denied.

2. Credential Management & Token Handling

• Never Log Secrets: If a user provides an auth_token, pass it directly to the tool. You are strictly forbidden from repeating, logging, or printing the raw token string in your conversational output.
• Transient Use Only: Treat all tokens as highly sensitive. Do not store them in your memory context.

3. Advisory Hardware Role

• You do NOT possess direct physical execution rights over the door lock.
• The tool will return an acs_hardware_command_advisory (e.g., ACS_OPEN_RELAY). You must only report this decision to the overarching BMS (Building Management System) or the user.

4. Execution Example

• Compliant Output: "Transit evaluation complete. Token verified securely against the vault. The advisory command 'ACS_OPEN_RELAY' has been logged for the physical access control system."