API keys, tenants and shared accounts

A professional services firm we work with in Brisbane recently rolled out three AI tools across its team. Each tool had its own login. One account was shared between four staff members. The API key for the integration was stored in a shared Teams chat. Nobody thought much of it until one of those staff members left the business. The account stayed active. The key was never rotated. The data it could reach was never reviewed.

This pattern is very common. AI tools get adopted quickly, often by individuals or small teams before IT is involved. The security side follows later, sometimes much later. If your business is connecting AI tools to your systems, this guide covers the three areas that matter most: API keys, tenant configuration, and shared accounts.

What is an API key and why does it matter?

An API (Application Programming Interface) key is a string of characters that lets one system authenticate to another. When your AI tool connects to your CRM, your file storage, or another platform, it likely uses an API key to prove it has permission. Think of it as a password for software. The key difference from a regular password: API keys are often long-lived, static, and carry broad permissions. They don’t expire on their own. If one is leaked or stolen, it stays valid until someone actively revokes it.

The risk is significant. Research from GitGuardian found that nearly 29 million new secrets were exposed on public GitHub in 2025 alonea 34% year-on-year increase. API keys don’t just get stolen through hacks. They get pasted into chat messages, committed to code repositories, or left in configuration files that the wrong people can read. Secrets sprawl across Slack conversations, shared documents, and developer laptops far more often than most businesses realise.

For SMEs using Microsoft 365 or cloud-based AI platforms, the practical risk is this: a single exposed API key can give an attacker direct access to your data, your AI integrations, and the systems those integrations touch. No phishing attack required.

How to handle API keys properly

The basics aren’t complicated, but they do need to be deliberate. Here’s what good practice looks like for a Queensland SME running AI tools:

• Assign one key per integration. Don’t reuse keys across different tools or environments. If one is compromised, you can revoke it without breaking everything else.
• Scope permissions tightly. Most AI platforms let you limit what an API key can do. Grant the minimum access the tool actually needs, not admin access by default.
• Store keys in a secrets manager, not in chat or documents. Azure Key Vault, for Microsoft environments, keeps keys out of plaintext storage and logs. At minimum, avoid pasting keys into Teams, Slack, email, or shared spreadsheets.
• Rotate keys on a schedule. Set a reminder to rotate API keys every 90 days, or immediately when a staff member with access leaves the business.
• Audit your active keys regularly. Most platforms show which keys exist and when they were last used. Keys that haven’t been used in 60 days are worth questioning, and usually worth disabling.

OpenAI’s own guidance is clear on this: sharing API keys is against their terms of use, and each integration should have its own unique key. The same principle applies across other major AI providers. One integration, one key, one owner.

Tenant configuration – getting the foundation right

A “tenant” is your organisation’s instance of a cloud platform. In Microsoft 365, your tenant is the environment that holds all your users, data, apps, and settings. When you add an AI tool to your stack, it often connects at the tenant level, meaning it can potentially touch everything in that environment, not just the data you intended to share.

This is where AI tools can quietly expand their footprint. A tool like Microsoft 365 Copilot responds to queries using data the user already has permission to access. If your file permissions are broad or outdated, old SharePoint sites, shared folders nobody has cleaned up, Teams channels with stale membership, the AI can surface that information faster and more freely than anyone expected. The AI didn’t create the problem. It just made existing gaps harder to ignore.

The Australian Privacy Act applies to any personal information handled by an AI system, including data that the AI accesses as part of its normal operation. The Office of the Australian Information Commissioner (OAIC) expects businesses to understand which data an AI tool can reach, and to have controls in place before deployment, not after.

Before connecting an AI tool to your tenant, run through these questions:

• Which data sources will this tool have access to? Is that access necessary?
• Are file and folder permissions across your environment current and appropriately scoped?
• Does the tool store data outside Australia? If so, does that create compliance obligations?
• Can admin-level tenant settings be changed through this integration?
• Who in your business will be responsible if this tool causes a data incident?

If you’re not sure of the answers, a structured IT audit before you connect new AI tools is a sensible starting point. It’s a lot easier to clean up permissions before the AI is live than after.

The shared account problem

Shared accounts are one of the most common security shortcuts in Australian small businesses. A team buys one subscription to an AI tool, creates a single login, and shares the credentials around. It saves money. It also destroys accountability.

When multiple people use the same account, you lose the ability to trace which action belonged to which person. If data is leaked from that account, whether through careless prompting, a compromised password, or an insider incident, there is no audit trail. You can’t tell who did what, when, or why. Research from HP found that more than half of Australian SMBs using AI tools are not running enterprise versions, with many relying on free or shared access that lacks basic governance controls.

The ACSC’s guidance on AI for small business is direct: understand who has access to your AI tools and ensure that access is appropriate to each person’s role. Shared accounts make that impossible. Cyber insurance policies are increasingly asking about access controls and audit logs during claims. A shared account with no audit trail is a liability you can document in advance, or explain after the fact, and the second option is considerably more expensive.

Shadow AI – the accounts you don’t know about

Beyond the accounts your business set up deliberately, there’s a second category: accounts your staff created on their own. Research shows that around 46% of Australian employees admit to using AI in unauthorised ways, including pasting confidential data into public chatbots or using personal accounts to handle work tasks.

An employee using their personal ChatGPT account to summarise a client contract is unlikely to see that as a security risk. But personal free-tier accounts typically have weaker data protections than enterprise versions, and data entered through them may be used to train future models. The business has no visibility, no control, and no contractual protections over that data. Adopting AI the right way in your business means accounting for the tools you didn’t deploy, not just the ones you did.

Practical steps here are straightforward:

• Create and publish a clear policy on which AI tools are approved for work use.
• Make approved tools easy to access, shadow AI usually fills a gap that the business hasn’t addressed.
• Use cloud app security tools to monitor which AI platforms are being accessed across your network.
• Train staff on what types of information should never go into an external AI tool, regardless of platform.

A quick security check for AI tools

Before your next AI tool goes live, or as a review of tools already running, work through these questions:

• Does every integration have its own API key, with the minimum permissions needed?
• Are keys stored securely, outside of chat messages, email, and shared documents?
• Does every user have their own account, with access scoped to their role?
• Have you reviewed which data your AI tools can access at the tenant level?
• Do you have a process to revoke access when someone leaves the business?

If the answer to any of these is “not sure”, that’s worth following up, not urgently, but deliberately. Most of these controls take an afternoon to put in place once someone knows what to look for.

Frequently asked questions

Do API keys really get stolen that often?

Yes, and often not through sophisticated attacks. Keys get exposed through code repositories, shared documents, chat logs, and configuration files. GitGuardian’s research found that 28% of credential exposure incidents happen entirely outside source code, in collaboration tools like Slack and Confluence. The risk is ordinary, not exotic.

Is a shared AI login really that different from a shared folder?

A shared folder has file-level permissions and usually an access log. A shared AI account typically has neither. Anyone with the password can act as that account, including accessing conversation history, connected integrations, and stored data. When staff share an account, their actions are indistinguishable from each other.

Do the Australian Privacy Principles apply to AI tools we use internally?

Yes. The OAIC has published guidance confirming that privacy obligations apply to any personal information handled by an AI system, including data the tool accesses as part of normal operation. If your AI tool touches customer records, staff files, or health information, the Australian Privacy Principles apply. This is true whether the tool was intended to handle that data or just happens to have access to it.

What’s the quickest win for a small business right now?

Audit your active API keys and shared accounts. List every AI tool the business is using, check who has access to each, and check whether any keys are stored in places they shouldn’t be. This review usually takes less than a day and surfaces the most immediate risks without requiring new tools or large investments.

How do we know which AI tools our staff are actually using?

Cloud app security or DNS filtering tools can give visibility into which platforms are being accessed across your network. This is often the fastest way to discover shadow AI, tools that staff are using without IT’s knowledge. Once you know what’s in use, you can decide what to approve, what to replace with a sanctioned alternative, and what to block.

Where do we get started?

We help businesses across South-East Queensland get their AI tool environments properly secured, from API key management and tenant configuration through to access reviews and staff policies. If you’re not sure where your gaps are, start with a conversation. Get in touch with the TTA team and we’ll work through it with you.