System Users and Automation Access: Non-Human Identities in a Business Container

Editorial team Spend Ledger

What a non-human identity is

A non-human identity is an access identity used by software rather than by a person signing in interactively. In a business advertising setup, it can let an approved reporting tool or script request data without relying on an employee’s personal login. Some platforms describe this type of identity as a system user and make it available within a business-level container.

The identity is not a separate human account, nor is it a substitute for the people who administer the business. It is a way to assign permissions to a specific technical actor. A person still needs to create and manage it, decide what it can access, and respond if its access is no longer appropriate.

This distinction matters because automation and human access have different needs. A reporting process may need to read campaign results regularly, while a staff member may need to make changes, manage billing, or review security settings. Giving both the same broad access makes it harder to understand what is necessary and who is responsible.

Platform terminology and available controls can change. Before setting up an identity, consult the platform’s official help pages on business containers, system users, asset access, authentication, and API or reporting permissions. Use those pages as the authority for current requirements, available options, and any restrictions.

Why the business should own it

A business-level identity should be controlled by the business that owns or administers the advertising assets, not by an individual employee or outside contractor. That keeps the access relationship attached to the organisation’s working structure rather than to one person’s employment, personal login, or changing role.

Business ownership also makes continuity easier to manage. If a staff member leaves, changes responsibilities, or loses access, the organisation can review the identity and the tools connected to it without treating the person’s login as the automation credential. Responsibility remains with the business administrators who are authorised to manage the container and its assets.

This is a governance choice, not a way to transfer or disguise ownership of an advertising account. The business should have legitimate authority over the assets and follow the platform’s applicable rules. A purchased account is a work tool and a purchased good; acquiring one does not remove platform requirements, change who is authorised to administer it, or make an automation identity an alternative to required verification.

For an agency or other service provider, agree in writing who owns the business container, who creates and controls the identity, what work it supports, and how access will be removed when the engagement ends. Do not let unclear contract language substitute for the platform’s own ownership and permission rules.

Match permissions to the task

Start by describing what the automation needs to do in plain language. A tool that produces a read-only performance report generally does not need permission to edit campaigns, manage people, or change business settings. A process that performs an approved operational task may need additional access, but each added permission should have a clear purpose.

Assign access to the relevant assets and functions rather than granting broad control by default. Keep administration of the business container separate from routine reporting where the platform allows that separation. Avoid giving an identity access to every advertising asset merely because it is convenient during setup.

Review permissions from the perspective of the task, not the person who configured it. Ask whether the tool can access only the necessary data, whether it can make changes, and whether it can reach assets outside the intended scope. If the platform offers roles or permission levels, use the narrowest level that supports the documented work.

Permissions should also fit the platform’s terms and policies. Do not use automation to bypass a review, circumvent a restriction, evade a limit, or avoid a required verification. If a tool’s intended function conflicts with platform rules, stop and resolve that issue through official guidance rather than expanding access or changing identities.

Create a clear record of the tool

An identity without a documented purpose can become difficult to assess later. Maintain an internal record that connects the identity to the software or script using it, the business purpose, the assets it can reach, and the person or team responsible for oversight. Record when the access was approved and what conditions would prompt a review, without treating the record as a substitute for platform controls.

Use a descriptive internal label where the platform permits one. It should help administrators recognise the function, such as reporting or an approved data workflow, without including secrets or sensitive personal information. Avoid vague labels that make several unrelated tools appear to be one system.

The record should explain the expected data flow at a useful level: what information the tool requests, where it is processed, who can see its output, and whether it stores information beyond the immediate task. Keep this description accurate as the integration changes. If a vendor or internal team modifies the tool, reassess its access rather than assuming the original approval still applies.

A simple inventory can be kept in the business’s normal access-management process. It should not contain the actual credential. The inventory is for accountability and review; credentials belong in an appropriately protected secret store, not in general notes, shared documents, or source files.

Protect and rotate credentials

Treat credentials issued to a non-human identity as sensitive access keys. Anyone who obtains them may be able to act with the identity’s permissions, subject to the platform’s controls. Limit access to the people and systems responsible for operating the integration, and use the platform’s supported authentication and credential-management methods.

Store credentials in a managed secret-storage system intended for confidential values, if one is available within the organisation’s approved environment. Do not place them in code repositories, ordinary configuration files, chat messages, tickets, or logs. Avoid sending them to a person simply because that is the quickest way to troubleshoot a connection.

Rotation means replacing an active credential through the platform’s supported process and updating the authorised integration so it uses the replacement. Plan the change so the old credential is no longer usable once the new one is in place and the integration has been checked. Follow the platform’s help pages for the exact process; do not assume that a credential can be renewed or revoked in a particular way.

Review and rotate credentials when access may have been exposed, when the responsible tool or provider changes, or when the business’s security process calls for it. If exposure is suspected, use the official controls to revoke or replace access and investigate the event. Rotation is not a reason to conceal activity or maintain access that the business no longer authorises.

Monitor use and review access

Automation should be observable. Where the platform provides access history, activity records, alerts, or other administrative visibility, use the available controls to review whether the identity is being used as expected. The records should help administrators investigate unusual activity and understand which process is associated with an action.

Set a review process that reflects the organisation’s security practices and the sensitivity of the accessible data. During a review, confirm that the identity still has a valid business purpose, the tool is still in use, its permissions remain appropriate, and the responsible people are still accountable for it. Remove access that is no longer needed.

A failed report or unexpected change can have several causes, including a permission change, an expired or revoked credential, a platform-side change, or a problem in the integration. Do not respond by granting wider access automatically. Check the platform’s official troubleshooting guidance, the tool’s own records, and the business’s documented configuration. Escalate through official support channels when the cause is unclear.

Keep the review proportionate and factual. The goal is not to create a claim that every action can always be attributed perfectly, but to maintain enough context to make access decisions and investigate issues responsibly.

Handle staff and provider changes cleanly

When a person changes role or leaves, review their individual access separately from the non-human identity. The identity should not depend on a former employee’s personal login, and its credentials should not be informally passed between people. Confirm that current administrators can manage it through the business container and that the approved integration remains under business oversight.

When a provider’s work ends, establish which integrations will stop, which credentials must be revoked or replaced, and who will verify that access has been removed. These arrangements should be agreed in writing before work begins, especially where an outside party configures reporting or automation. The agreement should clarify responsibility for data handling, maintenance, incident notification, and removal of access, while remaining consistent with platform rules.

If the business cannot identify who controls a credential or which tool uses it, treat that as an access-management problem. Use official platform controls and support routes to establish the current state. Do not create another identity to work around a restriction or an unresolved ownership question.

Keep the setup within platform rules

A non-human identity is an administrative mechanism, not a loophole. It should support legitimate business work within the platform’s permissions, policies, and verification requirements. It must not be used to continue activity that has been restricted, disguise who controls an account, spread access across identities to avoid a limit, or bypass enforcement.

Before connecting a reporting tool or script, confirm that the method is allowed and that the business has authority to grant the requested access. If the platform requires a particular review, approval, verification, or support process, follow it. If access is denied or an account is restricted, use the platform’s official appeal and support channels and address the underlying cause.

The platform’s own help and policy pages are the right place to check current terminology, supported authentication methods, asset permissions, and requirements for automation. Those details can change, so avoid relying on old setup notes or assumptions from another business. A well-managed identity has a defined owner, a narrow purpose, limited permissions, protected credentials, and a current record of the tool that uses it.