By Karl Lehnert, Director, DevProStudio
An MCP server can give an AI assistant access to files, databases and business actions in minutes. That convenience is why its credentials deserve careful scrutiny.
A current security report warns that hardcoded credentials in public MCP files can open the door to attacks. For an Australian SME, the lesson is not “avoid MCP”. It is to treat every MCP connection as a privileged integration, with an owner, a defined reach and a working off-switch.
The backdrop is not theoretical. The Australian Signals Directorate recorded more than 87,400 cybercrime reports in 2023–24—about one every six minutes. It put the average self-reported cost for small businesses at $49,600. A secret copied into a repository or shared config can turn one convenient prototype into an expensive access path.
Here are seven checks to make the boundary visible before an agent touches a business system.
1. Name the system, identity and actions
Write down three things: which system the MCP server reaches, which identity it uses, and which actions that identity can perform. “Connects to CRM” is not enough. “Reads contacts through service account X; cannot export attachments or edit records” is testable.
If the connector documentation cannot explain its permissions, authentication method and data flow, it is not ready for production. A polished README is not a security model.
2. Remove secrets from code and config
API keys, refresh tokens and client secrets do not belong in a repository, an example JSON file, a desktop config checked into source control, or a prompt. Environment variables are better than literals, but they are not a complete secret-management system.
Use a managed secret store with access policy, versioning and audit history. The OWASP secrets-management guidance recommends managing the full lifecycle: creation, distribution, rotation, revocation and expiry. Scan repositories and build artefacts for accidental exposure, including history—not only the latest commit.
If you discover an exposed secret, removing the line is not remediation. Revoke or rotate the credential first, then investigate where it was used.
3. Give the connector its own identity
Do not run an MCP server under an owner's personal account. Shared identities destroy accountability; personal identities silently inherit permissions as staff roles change.
Create a dedicated workload or service identity for each environment. Development should not share production credentials. Give the identity only the scopes needed for the approved tools, ideally starting read-only. If the platform offers OAuth, use it properly rather than passing upstream tokens through the MCP server.
The MCP specification's security best-practices guidance explicitly warns against token passthrough and describes confused-deputy risks. In plain English: a server should not accept a token merely because another system issued it, then forward that authority somewhere else.
4. Put an expiry date on access
Long-lived keys are operational debt. Record the credential owner, issue date, expiry date and rotation procedure. Test rotation while the system is healthy; an untested runbook is a hope, not a control.
Also test revocation. Can you disable the connector without taking the underlying business system offline? Can you identify every running instance that holds the old credential? Those answers matter during an incident, when a ten-minute manual hunt feels very long.
5. Separate reads from writes
An assistant that searches a knowledge base has a different risk profile from one that can send email, change a customer record or approve a refund. Model that difference in permissions, not only in the prompt.
For write-capable tools, add a human approval step at the point of consequence. Show the operator the proposed action, target and important fields. Keep high-impact actions—payments, user administration, bulk deletion—outside the agent's direct authority unless there is a compelling, reviewed design.
This is where our advice differs from “just add guardrails”. Prompts are useful behaviour instructions. They are not a substitute for access control enforced by the destination system.
6. Log actions without logging secrets
You need enough evidence to answer who invoked a tool, which server handled it, what business object it touched, whether approval occurred, and whether it succeeded. You do not need bearer tokens, raw credentials or every piece of personal information in the log.
Design a redaction policy before production. Restrict access to logs and set a retention period. The OAIC's APP 11 guidance requires reasonable steps to protect personal information from misuse, loss and unauthorised access or disclosure. MCP call logs containing customer data are part of that obligation, not harmless debugging exhaust.
The privacy stakes are current: the OAIC received 595 data-breach notifications in July–December 2024, then the highest six-month total under the scheme; 69% involved malicious or criminal attacks.
7. Test the failure path in a sandbox
Before production, try the awkward cases. Ask the agent to access a record outside its role. Feed it content that attempts to override instructions. Interrupt the MCP server mid-action. Revoke its credential. Confirm that retries cannot duplicate a consequential write.
Use synthetic data, not copied production personal information. Record the expected result for each test and keep the evidence. For a broader release process, pair this with an AI-assisted delivery checklist covering tests, review gates and rollback.
A practical implementation pattern
This is a common implementation pattern, not a claimed client case study. A small team wants an agent to look up support tickets and draft replies. The first release uses a read-only service identity, retrieves only assigned ticket fields, and drafts into a review queue. Sending remains a human action. Credentials live in a managed vault; every lookup records the user, ticket ID and tool name, with message bodies excluded from general logs.
Only after the team has reviewed failures does it consider a send capability. That step gets a separate scope, explicit approval and a kill switch. The design is less flashy than a fully autonomous demo. It is also easier to price, insure, explain and operate.
How much control is enough?
Do not buy security tooling by checklist length. Price the connection by consequence:
- Low consequence: public or synthetic data, read-only access, no personal information. A dedicated identity, basic logging and expiry may be enough.
- Moderate consequence: internal or customer data, limited writes. Add managed secrets, narrow OAuth scopes, approval, monitoring and tested revocation.
- High consequence: money, identity administration, regulated data or bulk actions. Require formal threat modelling, strong separation of duties, independent security review and a rehearsed incident path.
Budget for setup and ongoing rotation, monitoring and review—not just the connector licence. The cheapest integration is not the one with the lowest monthly fee; it is the one whose authority you can understand and contain.
The decision before “connect”
MCP is useful because it standardises how AI applications reach tools and context. Standardisation does not make every server trustworthy, and it does not shrink the permissions you grant.
For Australian SMEs, the practical test is simple: if you cannot name the credential, owner, scope, expiry and revocation path, do not connect it to production yet. If you need help designing a custom agent integration with those controls built in, talk to DevProStudio. Our approach starts at the business-system boundary, not at the demo screen.
Frequently asked questions
Is MCP itself insecure?
No. MCP is a protocol for connecting AI applications to tools and context. Risk comes from how a server is implemented, what credentials it receives, which systems it can reach and how clients obtain consent. Review each server and connection independently.
Is an environment variable enough for an MCP API key?
It is better than hardcoding the key, but usually not enough for production. A managed secret store adds controlled access, audit history, versioning and rotation. Whatever the storage method, prevent the value from appearing in source control, prompts and logs.
Should an MCP server use a staff member's login?
Generally no. Use a dedicated workload identity with minimum scopes and separate credentials for development and production. Personal accounts blur accountability and can retain excessive access when a person's role changes.
What should we do if an MCP secret was committed to Git?
Revoke or rotate it immediately; deleting the line does not remove it from history or existing clones. Check access logs, identify affected systems, replace the secret wherever deployed, preserve evidence and assess whether personal information or regulated data was exposed.