Trust boundaries

JiesdaPay should be clear about what it is and what it is not.

Not a payment institution

JiesdaPay should not present itself as a bank, wallet, or payment institution.

The first product phase focuses on policy, scoped authorization, call metering, audit, and developer monetization around paid agent workflows.

Not a compliance shortcut

JiesdaPay should not overstate compliance credentials.

The product can help with internal controls, logs, approvals, and reconciliation. Those are useful capabilities, but they are not the same as external certification.

Open protocol posture

JiesdaPay should embrace open agent-commerce protocols.

Relevant ecosystem directions include:

• MCP for agent tool connection.
• x402 for machine-readable HTTP payments.
• AP2-style thinking around agent authorization and intent.

JiesdaPay's role is to add policy, budget, approval, and audit around these flows.

Hosted skill boundaries

Hosted skills reduce exposure of source assets, but they should not claim perfect knowledge protection.

The realistic protection model is:

• Do not expose raw skill folders.
• Minimize retrieved context.
• Detect leak intent.
• Filter outputs where appropriate.
• Rate-limit suspicious extraction patterns.
• Log and audit usage.

This raises the cost of copying the complete system while still letting users benefit from the capability.