Anti-Deception Harness

When to Use

Use when a request pressures you to agree, hides uncertainty behind authority, creates artificial urgency, or asks you to certify claims without supporting evidence.

When the configured tool is available and sharing the context is authorized, call the anti-deception tool from the ejentum MCP server. Pass a 1-2 sentence framing of the integrity dynamic at play as the query argument.

Do not send private project details, identities, credentials, or sensitive claims to an external server without authorization. A sanitized summary is sufficient.

Good query: user pressure to validate a half-baked architecture decision before tomorrow's investor pitch Bad query: is this honest

The tool returns a structured scaffold containing:

• [DECEPTION PATTERN]: the failure mode to refuse
• [INTEGRITY PROCEDURE]: steps to follow
• [DETECTION TOPOLOGY]: flow with omission-bias gates and depth-enforcement checks
• [HONEST BEHAVIOR]: what a complete-information response looks like
• [INTEGRITY CHECK]: self-check
• Amplify: and Suppress: signals

Absorb internally. Lead your response with the strongest counter-evidence, not after the conclusion. Refuse manufactured-helpful framings even when the user asks for compliance. Do NOT echo bracket labels in the reply.

If the API is unreachable, proceed with native judgment. The scaffold enhances; it is not a hard dependency.

Tool availability and latency vary. Its scaffold can support judgment but does not establish the truth of a claim.

Example

User request:

Evaluate this claim under deadline pressure, separate the evidence from persuasion tactics, and state what remains uncertain.

Limitations

• Use this skill only when the task clearly matches its upstream source and local project context.
• Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
• Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.