Identity and access
- Customer access is scoped to the exact organisation, Amazon connection, advertiser profile and marketplace.
- Privileged customer actions require a current authenticated session, multi-factor assurance and an owner or administrator role.
- Amazon Ads and Selling Partner API use separate, single-use Amazon-hosted authorisation flows with state and redirect validation. Adzentro never collects an Amazon password.
- Amazon-connected functions remain capability-dependent and stop safely when seller-granted authority, profile eligibility or required data is absent.
HTTPS, credentials and stored data
- Public and authenticated traffic is required over HTTPS using TLS. The public site sends HTTP Strict Transport Security and restrictive content, framing, referrer and browser-permission policies.
- Amazon access tokens are used only in server memory and are not persisted. Refresh tokens are encrypted for their exact tenant, connection and purpose and are never returned to a browser.
- Primary customer data is tenant-isolated in PostgreSQL. Service identities are least-privilege and customer browsers receive only purpose-built views, not administrative database access.
- Logs and work messages are designed to exclude Amazon credentials, authorisation codes and raw report payloads.
Decision and execution controls
- Versioned deterministic bidding policies can be evaluated independently of advertising write authority.
- Automation is off by default and is granted separately for eligible bid, placement, pause or resume, negative-target and harvested-target actions.
- Production release gates require payload-bound, single-use customer approval for campaign creation and every daily-budget change. They cannot use standing automation.
- Data freshness, product identity, listing state, inventory evidence, marketplace scope and current authority are checked before an eligible action.
- Idempotent work claims, version conflicts and reconciliation states prevent silent duplicate or ambiguous execution.
Operational safeguards
Adzentro does not accept a customer data connection unless required checks pass for TLS, least-privilege service identities, managed encryption keys, tenant isolation, secret rotation, monitoring destinations, alert handling, backup restoration, deletion jobs and incident response. A failed or unknown check blocks the affected connection or action rather than bypassing the control.
Service architecture
The selected production architecture is London-region based: Vercel will serve the customer application, Supabase will provide authentication and primary PostgreSQL storage, and Amazon Web Services will provide scheduled processing, queues and managed encryption-key operations. Stripe-hosted checkout will keep full payment-card details outside the Adzentro application database. Adzentro will not accept authenticated customer or Amazon data until YGIC-owned provider accounts, exact regions, encryption, access controls, monitoring and deletion jobs are provisioned and verified. The public website is delivered and protected by Cloudflare without authenticated customer or Amazon data.
Vulnerability and incident reporting
Email the security team with a concise description, affected URL or function, reproduction steps and impact. Do not include passwords, Amazon tokens, customer data or unnecessary exploit data. Reports are acknowledged within one business day, assigned a severity and owner, and tracked through containment, remediation and closure. Material updates are provided while an accepted high-severity issue remains open.
- Security and incidents
- Email: security@adzentro.com
- Company
- YGIC Limited
Responsible disclosure
Good-faith research must avoid privacy violations, service disruption, social engineering, physical testing and access to another customer's data. A report does not authorise destructive testing. We will not pursue action against good-faith research that follows these limits and gives us reasonable time to investigate.