31 lines
2.5 KiB
Markdown
31 lines
2.5 KiB
Markdown
---
|
|
name: development-security
|
|
description: Prepare safe authenticated development operations.
|
|
version: 0.1.0
|
|
author: SKIC maintainers, Hermes Agent
|
|
license: MIT
|
|
platforms: [linux]
|
|
metadata:
|
|
hermes:
|
|
tags: [delivery, governance]
|
|
related_skills: []
|
|
---
|
|
|
|
# Authenticated development boundary
|
|
|
|
Owns a non-secret authorization and exposure preflight for development operations. The consumer's identity/security policy remains authoritative for credentials; this skill does not establish credential names, issue credentials or approve recovery.
|
|
|
|
## When to use
|
|
Before authenticated development access, publication or collecting potentially credential-bearing failure evidence.
|
|
|
|
## Procedure
|
|
1. Read the bound security policy and exact authorized operation. Record only target origin, purpose, permitted action and policy source in the work record. Stop when the policy cannot be loaded or the action is outside authority.
|
|
2. Classify the interface (existing trusted session, supported runtime API or trusted login form) and check the destination origin against that authorized target before credential use. Reject unexpected redirects or insecure transport; do not weaken TLS/MFA/access controls.
|
|
3. Check required secret availability by presence only under the governing policy. Missing injection is a capability blocker, not permission to create a fallback credential, borrow an identity or ask for secret values in chat.
|
|
4. Keep credentials out of command arguments, URLs, files, logs, screenshots, patches and test fixtures. Use only the policy-approved secure runtime interface. If an error may contain a secret, redact it before retaining diagnostic evidence; never inspect, hash or measure secret values for debugging.
|
|
5. Perform only the authorized operation. Authentication success is not authority to administer accounts, rotate credentials, alter permissions, spend, destroy resources or access unrelated data.
|
|
6. Verify the requested operation separately from login. Report target/purpose, success/failure and non-sensitive readback only. Follow the bound session-reuse/cleanup policy; never persist a new credential store as a convenience.
|
|
|
|
## Pitfalls and verification
|
|
A valid token is capability, not consent; a generic 401/403 is not proof of a disabled account. Recovery requires a separately verified delegation and specialist procedure. Before handoff, inspect the intended evidence paths for credential exposure without printing secrets, verify the origin and action matched the authorization record, and retain no identity details unnecessary to the result.
|