Security
Security at Agency Pilot
Your clients trust you with their ad accounts, their analytics and their customers' enquiries. This page explains exactly how we handle that — including every permission we ask Google and Meta for, and why.
No passwords, ever
Clients sign in on Google's, Meta's and each platform's own page. Guided steps always invite your agency's own login. We never ask for, store or see a password to a client's account.
Least privilege, per link
You choose the access level per platform when you create a link. Owner-level access is never offered, and a link only requests the permissions its platforms need.
No guessing
If a client's login reaches several properties, ad accounts or Pages, nothing is granted until someone picks the right one.
Encrypted tokens
Connection tokens are encrypted at rest with AES-256-GCM, sent to platforms in headers (never in URLs), and never exposed to the browser.
Agency isolation
Row-level security in the database keeps every agency's data separate. A client login can only ever reach that client's records.
Everything on the record
Every onboarding link logs opens, connections, grants and completions, and admins are notified when a link completes.
Two kinds of access, kept separate
When a client uses an onboarding link, two different things can happen, and it's worth being precise about them because most tools blur them together.
The access your agency receives. Your Google login added to the GA4 property, your business portfolio assigned as a partner on the Meta ad account, the invitation to Google Ads. That access is created inside each platform, belongs to your agency, and stays until the client removes it there — whether or not you keep using Agency Pilot.
The reporting connection Agency Pilot holds. A token that lets us read the numbers for the client's dashboard. It's encrypted at rest, scoped to the permissions on the consent screen, expires or refreshes according to each platform's rules, and ends the moment either side disconnects it — from Connected accounts in Agency Pilot, or from the client's Google or Facebook settings.
Transparency
Every permission we request, and why
A link only asks for the permissions its platforms need. Here is the complete list.
| Permission | Used for |
|---|---|
| openid, email, profile | Shows you and the client which Google login a connection belongs to. |
| analytics.readonly | Reads GA4 traffic, engagement and conversions for the client's dashboard and reports. |
| analytics.manage.users | Only on a link that asks for access: adds your agency's login to the chosen GA4 property at the role shown to the client. |
| webmasters.readonly | Reads Search Console performance for the client's site. Read-only. |
| business.manage | Reads Business Profile performance and, only on a link that asks for access, adds your login as Manager of the one account the client chooses. |
| tagmanager.readonly | Lists Tag Manager accounts and containers so the right one can be chosen. |
| tagmanager.manage.users | Only on a link that asks for access: adds your login with the container permission shown to the client. |
| adwords | Reads Google Ads performance and, only on a link that asks for access, sends one user invitation to your login. |
| datamanager | Only when you switch it on for a client: sends sold jobs to their Google Ads account as offline conversions. |
| content | Only on a link that asks for Merchant Center access: invites your login to the account the client chooses. Products and feeds are never read or changed. |
Meta (Facebook Login for Business)
| Permission | Used for |
|---|---|
| ads_read | Reads spend and delivery for the ad account the client shared. |
| ads_management | Manage links only: assigns your business portfolio as a partner on that ad account. Nothing else is written. |
| business_management | Manage links only: required by Meta to assign a partner on an asset owned by a business portfolio, and to detect your own Business ID. |
| pages_show_list | Lists the Pages the person manages so they can pick one. |
| pages_manage_metadata | Manage links only: assigns your business as a partner on a Page that isn't owned by a business portfolio. |
Every Meta API call is signed with an app secret proof. When a client removes Agency Pilot from their Facebook settings, Meta notifies us and the connection is marked revoked immediately; data-deletion requests get a status page the requester can check. Platform-by-platform detail is on each integration page.
Inside your workspace
- Roles. Owner, admin, member and viewer, with per-member permissions on top, enforced on the server for every request.
- Client logins. A client portal user can only reach their own business's records — never another client's, and never your internal notes, invoices to other clients or tasks.
- Two-factor sign-in. Authenticator-app 2FA for agency users, required before anything protected loads once it's on.
- Sign-in. Email and password or Sign in with Google, on short-lived signed session tokens.
- Credentials you give us. Telephony, CRM, mailbox and Conversions API credentials are stored encrypted, used only for the feature you connected them for, and deleted when you disconnect.
On your clients' websites
- Recording is off by default. Session recording is an add-on, switched on per client, with retention of 30, 60 or 90 days.
- Never recorded. Password and payment-card fields are always hidden, and pages that contain them aren't recorded at all. Typed text is hidden unless the client turns it on, with a second switch for sensitive fields.
- Consent. An optional consent banner can gate recording for everyone or visitors in chosen states, and honours Global Privacy Control.
- Retention. Raw visit data is kept 13 months, page snapshots 90 days, and recordings are deleted at expiry or 7 days after an agency's paid period ends.
- The fraud network. Signals shared across agencies to spot fraud use salted, one-way hashed identifiers. No agency can see another agency's visitors or leads.
Details for the people visiting your clients' sites are in the website visitor notice.
Infrastructure
Agency Pilot runs on managed cloud infrastructure in the United States, behind a content delivery and network security layer, with the database, authentication and file storage on a managed database platform. Traffic is encrypted in transit with TLS. Payments are handled by a PCI-compliant payment processor; we never see or store card numbers. The categories of providers are on the subprocessors page, and our commitments as a processor are in the Data Processing Addendum.
Server-side validation backs every check the interface makes; rate limits protect sign-in and public endpoints; webhooks are verified by signature; and errors are monitored so problems are fixed before they're reported.
Reporting a vulnerability
If you think you've found a security issue, email support@agencypilot.io with "Security report" in the subject. Please give us a reasonable chance to fix it before disclosing it, and don't access or change other people's data while testing. We'll acknowledge your report and keep you updated.
Security questions
- Is it safe to give a marketing agency access through Agency Pilot?
- Yes, and safer than the usual alternatives. Nobody shares a password; the client signs in on each platform's own page, sees the exact access being requested, and the agency receives the platform's own user or partner access, which the client can remove at any time.
- What happens to access if an agency stops using Agency Pilot?
- The access the agency received lives in Google, Meta and the other platforms and stays until the client removes it there. Agency Pilot's reporting connection is separate; it ends when either side disconnects it or the account is closed, and the stored tokens are deleted.
- Can one agency ever see another agency's data?
- No. Every table is protected by row-level security tied to the agency, and every request is checked on the server against the signed-in user's role.
- Where is data hosted?
- In the United States, with established cloud providers for the database, authentication, file storage and application hosting. The subprocessors page lists each category of provider, what it does and where; customers can request the named list.
- Do you have SOC 2?
- Not yet. We'd rather tell you that than imply it. If your procurement team needs a security questionnaire answered, email us and we'll complete it.
Access your clients can say yes to
Start a 14-day trial with 300 credits and send your first onboarding link today.
Evaluate agency software security with specific questions
Agency software connects people, client records, and third-party accounts. A useful security review identifies which information is involved, which person can access it, and which permissions exist outside the application. Agency Pilot’s published security information describes the connection model and controls used in the product. Read those details alongside your agency’s own obligations and the requirements of the client you serve.
Avoid turning a single control into a blanket conclusion. Token encryption, database isolation, and role checks address different parts of the system. If your procurement process needs information not covered here, ask for the precise document or answer. The page does not claim a SOC 2 certification; a requirement for a specific certification should be discussed directly rather than inferred from the presence of other controls.
Distinguish permission scope from the purpose of access
A provider may use one permission scope for several operations. The relevant question is what the Agency Pilot workflow does with that permission and which client asset is selected. The scope descriptions above explain the purpose of the supported flows. Match them to the platforms included in your onboarding link and the role requested from the client.
The agency also needs an operating procedure. Choose an appropriate role, confirm the correct business, avoid collecting client passwords, and review access when people or contracts change. Technical controls and clear responsibilities work together. If an employee has a problem, a precise description of the account and action helps investigation more than forwarding a broad set of client records.
Prepare a focused security review for procurement
Start with the actual requirement your organisation needs to satisfy. A questionnaire may ask about authentication, data isolation, hosting, processing arrangements, subprocessors, retention, or third-party permissions. Separate questions answered by the published material from those that require a direct response. Reference the relevant page and state what remains unclear. This makes the review easier to complete accurately and avoids substituting a broad marketing statement for a specific control or contract requirement.
Keep conclusions proportionate to the evidence. A description of encryption is not a claim about every security control, and a statement about a workflow does not establish a certification. If you need a named assurance report, custom contract language, or confirmation of a processing location, ask for that exact item. Record the response and its date alongside your decision. Your agency should also review its own responsibilities, including account administration, client permissions, tracking configuration, and offboarding. A product review works best when it identifies both the provider’s commitments and the operational practices your team must maintain.
Review both application connections and provider permissions
An engagement can create several distinct relationships: access to the agency workspace, a client portal login, a reporting connection, and permissions granted directly within an advertising or analytics platform. Make an inventory before ending the service so you know which relationship each action affects. Removing a reporting connection should not be assumed to remove the agency’s separate provider-level user or partner permission. Likewise, changing a staff role in one application does not necessarily alter their access elsewhere.
Agree with the client who will perform each removal and which business records they need before the engagement ends. Check the provider’s own access settings where applicable, and verify the result instead of relying only on the completion of an internal checklist. Preserve an appropriate record of the handoff without copying unnecessary personal data. If a particular deletion, export, or retention requirement matters to the contract, review the published policy and obtain clarification. This turns offboarding into a documented transfer of responsibility rather than a vague assumption that cancelling a subscription disconnects every system.
Frequently asked questions
What should I review before connecting a client account?
Identify the required asset, the authorised account owner, the agency identity receiving access, and the role needed for the service. Read the relevant integration page. Check that the client understands the request before proceeding. This keeps the permission decision tied to the agreed work rather than a general request for maximum access.
Why are reporting tokens different from user permissions?
A reporting token lets the application perform supported operations with the provider. A user or partner permission grants the agency access inside that provider. They can exist independently and have different removal paths. Review both during troubleshooting and offboarding so ending one relationship is not mistaken for ending the other.
Does this page establish a security certification?
No. The page describes product controls and explicitly states that Agency Pilot does not currently claim SOC 2. If your organisation requires a particular assurance report or certification, ask about that requirement directly. Do not infer a certification from encryption, hosting, or another individual security statement.
What should a procurement questionnaire include?
Send the actual questions and identify any requirement that determines whether you can proceed. Reference published answers where appropriate and flag gaps clearly. Include a suitable business contact and deadline. Avoid sending unnecessary client data; most control questions can be answered without examples containing personal customer information.
How should an agency handle client passwords offered by email?
Use the documented provider permission or invitation flow instead of collecting shared credentials. Explain to the client which identity should receive access and which role is needed. Keep authentication secrets out of tickets, project notes, and screenshots. If a secret has already been exposed, follow the relevant account recovery or credential-change process.
What information belongs in an access inventory?
Record the provider, asset identifier, business owner, agency identity, granted role, and person who verified it. The inventory should describe the relationship without storing passwords or tokens. It becomes useful when a teammate changes role, a connection fails, or a client asks the agency to remove access.
How should I review a new team member’s access?
Match access to the responsibilities they will perform and check the relevant role controls. Consider both the agency application and external platforms. Give the teammate a clear process for requesting additional access when needed. Review the arrangement when their work changes rather than treating the initial invitation as permanent.
Can a provider consent screen look broader than the task?
Provider scopes can cover a category of operations, while the application uses them for a defined workflow. Read the purpose listed on this page and the relevant integration guide. If the scope does not make sense for your intended use, ask for clarification before connecting rather than dismissing the concern or inventing an explanation.
What should I check before sharing a report or video?
Verify the intended client, the audience, and the available sharing controls. Review the content for unrelated account details or personal information. A correctly scoped application does not remove the need to inspect material that a user chooses to share. Apply the same care you would use when sending a client attachment.
How should I report a suspected vulnerability?
Use the private security contact route on the contact page. Describe the observed behaviour, affected area, and safe steps to reproduce it. Avoid unnecessary access to other people’s data and exclude secrets from the report. Keep the communication private while the team investigates the issue.
Where can I review data processing information?
Read the privacy policy, data processing agreement, and subprocessors information linked from the site. These serve different purposes from a feature description. If your contract requires a specific arrangement not explained there, request clarification before assuming it is covered. Keep the response with your procurement record.
What should I do when a client engagement ends?
Review the application relationship, reporting connections, and provider-level access separately. Agree who will remove each permission and what business records are needed for the handoff. Verify the resulting state in the relevant systems. The security page explains why cancelling one connection does not necessarily remove every agency permission.
Does a security review end after purchasing?
No. Your own operating practices still need review when users, services, integrations, or client requirements change. Keep an inventory of access and a clear escalation route. Revisit important requirements as part of normal account management rather than assuming the original purchasing decision covers every future workflow.
What should a safe support screenshot show?
Show the relevant interface state and error while removing passwords, tokens, unrelated records, and unnecessary customer details. Include the action and expected result in text. This gives support enough context to investigate without turning a routine ticket into a broader copy of confidential client information.
How can I ask about a requirement not listed here?
Name the requirement precisely and explain the workflow or contract that makes it important. Ask for the supporting information you need instead of requesting a general assurance that everything is secure. The contact route can help resolve those questions, and the answer should become part of your own documented evaluation.