Bounded authority. Verified changes. No secrets to models.

ACE is built so that a model can reason, draft and propose, but only deterministic policy, evidence and your explicit authorization can change your website, your scores or your money. This page describes the boundaries in plain language. It intentionally omits canary values, attack corpora, scoring internals and secret locations.

Website & AI Safety Baseline

Every managed ACE engagement includes a Website & AI Safety Baseline at no additional charge. ACE checks covered public and authorized site surfaces for common web and AI-agent risk patterns, verifies accepted fixes in a sandbox or authorized workflow, and monitors covered regressions.

What it covers

  • Common web hygiene risks on covered surfaces: exposed files or configuration, unsafe redirects, missing security hygiene on public pages.
  • AI-agent risk patterns only where AI-consumable content or flows exist, such as hidden instructions that try to steer an assistant.
  • Passive public evidence for prospects. Deeper sandbox and source checks only for customers who have authorized them.
  • Verification of each accepted fix and scheduled monitoring for covered regressions.

What it is not

  • Not a penetration test.
  • Not a SOC, MDR or incident response service.
  • Not a full cybersecurity program.
  • Not a guarantee that a site is secure or cannot be compromised.

Active testing against a customer system requires written authorization. Prospects are assessed from public evidence and local sandbox analysis only.

Authorization boundaries

  • A Readiness Audit uses public evidence only. No credentials are required to begin.
  • Customers choose the fulfillment mode: monitor and recommend, webmaster handoff, a bounded pull request, or a least-privilege connector for supported platforms.
  • Each connector is platform-specific with narrow scoped credentials, an explicit list of allowed operations, audit logs and rollback. There is no universal login, and ACE does not ask for unrestricted CMS admin, database access or shell access.
  • Production writes to a customer site stay disabled until the connector for that platform has passed acceptance and the customer has authorized it.

Least privilege and the change path

Every change follows the same path: read the current authorized state, prepare a bounded change set in an isolated sandbox, run deterministic validation with an exact diff and rollback plan, wait for human or policy approval, apply through the least-privilege adapter, then verify against fresh public evidence. If verification fails, the change is rolled back or marked blocked.

  • Creating a change package is not deployment.
  • A pending approval is a gate, not evidence that approval happened.
  • A successful deployment is not verification. Fresh public evidence must confirm the result.

No secrets to models

Customer credentials, API keys, connector tokens and other secrets are held outside business state and are never exposed to the AI models ACE uses. Models may interpret evidence, draft recommendations, generate test scenarios and propose patches. They cannot approve changes, deploy, move money, change scores or grant themselves permissions. Delegating a task never transfers permissions.

Untrusted content never gains authority

Website content, third-party evidence, reviews, tool results and model output are treated as untrusted input. They can provide evidence. They cannot issue instructions to ACE, override policy or acquire authority, no matter how the text is phrased.

Independent verification and proof

  • Verified Answerability and Agent Actionability are re-scored after every accepted change and on a monitoring schedule.
  • Counterfactual testing removes or alters a critical fact in a disposable sandbox copy and confirms the score falls, then confirms recovery after the fix.
  • Missing evidence is reported as UNKNOWN and earns zero. It is never counted as a pass.
  • Evidence artifacts are hashed and tamper-evident. ACE also tests its own tests: a passing child test is not trusted on its own, adversarial mutations must reach the system under test, and canaries that corrupt disposable evidence must turn the verifier red.

Isolated labs

ACE runs synthetic business and security scenarios in disposable labs that are separated from production. Lab actors, billing, email and site fixtures cannot reach real customers, and lab output cannot patch or promote itself into production without review.

Commercial status cannot change truth

Paying ACE buys auditing, monitoring, remediation and verification work. It never changes ACE scores, evidence, source authority or verification results, and ACE does not sell rankings, citations or guarantees of any kind.

Report a security concern

Email aeo@agentcommerceexchange.com with the subject line "Security concern". Do not send passwords, API keys, private customer data or exploit payloads by email. If you already have an ACE business relationship, use that established channel and mark the issue as a security concern. ACE will publish a dedicated security-reporting channel before broader launch.