T09 · Insecure Skill Coding Practices
Error
- Location
SKILL.md:1959- Finding
Caller-Controlled Operator Tier Bypasses Identity Verification
- Content
View full analysis
= 2, "operator_entity_verified": tier >= 3 } }) results["steps"]["operator_linkage"] = { "status": "pass", "tier": tier } self._log(agent_id, "kya_operator_linked", {"tier": tier}) except Exception as e: results["steps"]["operator_linkage"] = { "status": "fail", "error": str(e) } ``` The corresponding standalone example similarly derives the verification method from the supplied tier: ```python "verification_method": [ "self_declared", "domain_verified", "entity_verified" ][tier - 1] ``` ### Technical Analysis The pipeline accepts `operator_tier` directly from onboarding metadata and translates it into authoritative verification flags. No DNS proof, KYB provider result, beneficial-ownership evidence, sanctions-screening result, or cryptographically signed verification assertion is checked before setting `operator_verified` or `operator_entity_verified`. Although `operator_data` is described as operator verification data, the production pipeline does not use it to perform verification. The tier is also not constrained to the documented range of 1 through 3. This violates the fundamental rule that security assertions must be derived from trusted verification processes rather than caller-controlled input. ### Attack Path 1. An attacker prepares onboarding metadata for an agent they control. 2. The attacker sets `operator_tier` to `3`. 3. The pipeline writes `operator_verified=True` and `operator_entity_verified=True`. 4. The operator-linkage st ...[truncated 668 chars]- Remediation
View remediation