AI Agents Need More Than Login Credentials

AI agents are changing a small but important question.

Until recently, many AI discussions were about access to information: may this system read a document, inspect a repository, analyse a ticket or answer a customer question?

Now the more important question is becoming: may this system act?

That is a different kind of risk. A chatbot that gives a wrong answer is annoying. An agent that runs the wrong tool, changes a database, triggers an API call or starts a deployment can create real damage.

This is why a current discussion on X is worth paying attention to. Teams are connecting agents to tools, MCP servers, repositories, cloud services, internal APIs and automation workflows. They are solving the login problem, but not always the execution problem.

In other words: an agent can be authenticated and still be allowed to do things it should never do in that moment.

For founders, CTOs, product owners and mid-sized business teams, this is not an abstract security issue. It is an architecture issue. If you want to use AI agents in serious products or internal operations, you need a clear answer to which actions are allowed, which actions need approval and which actions must stay outside the agent’s reach entirely.

Authentication is not authorization

In everyday product work, these terms often get blurred.

Authentication answers: who or what are you?

Authorization answers: what are you allowed to do?

With human users, the difference is familiar. An employee may log in correctly and still be unable to read salary data, delete a production database or approve a payment. Identity alone is not permission for every action.

With AI agents, this separation can become dangerously vague.

An agent receives an API key, a GitHub token, access to an MCP server, a browser, a terminal or an internal tool. The connection works. The agent can get things done. That is exactly why it is useful.

But if that token is too broad, productivity becomes operational risk.

The agent no longer merely has context. It has impact.

It can read, change, move, delete or publish data. It can start expensive processes. It can write sensitive information into the wrong system. It can execute an action that sounds plausible inside the conversation but is wrong in the actual business context.

The problem is not that AI agents are malicious. The problem is that probabilistic systems are not a substitute for stable security boundaries.

A language model can interpret intent. It should not be the only thing deciding whether a risky action is allowed to execute.

MCP and tool access make this urgent

The Model Context Protocol and similar tool-integration patterns are important. They make it easier to connect AI systems to data sources, development tools and business systems.

That is a good thing. Without these interfaces, many AI applications stay superficial.

An agent that can only write text is limited. An agent that can read tickets, change code, run tests, inspect logs, prepare support cases or execute internal workflows is much more valuable to a company.

But tool access moves AI from a knowledge system to an action system.

As soon as an agent can use tools, new questions appear:

• May the agent only read, or may it write?
• May it execute changes directly, or only propose them?
• Which systems are production-critical?
• Which actions require human approval?
• Which credentials are short-lived and task-specific?
• How is each action logged?
• Is there a rollback or recovery path?
• Who is alerted when an agent attempts something unusual?

These questions sound boring. That is exactly why they matter.

Serious software is rarely made safe by one spectacular decision. It becomes safe through clear boundaries, good defaults and systems that behave sensibly even when someone, or something, makes a mistake.

The dangerous default: “the agent can do what the user can do”

A common mistake is to give agents the same rights as the person using them.

It feels practical. A developer can access the repository, ticket system and staging environment, so the agent gets the same access. An operations person can trigger deployments, so the agent can do that too. A product owner can export customer data, so the agent receives access to the relevant tool.

For simple tasks, this removes friction.

For production systems, it is risky.

A person brings context that the permission system does not see: experience, responsibility, memory of previous incidents, customer promises, internal agreements and the ability to feel that something is off. An agent can simulate parts of that reasoning, but it does not carry the responsibility.

That is why agents should not automatically inherit their user’s full permissions.

They need their own roles.

A good agent role is narrower than a human role. It is designed for specific tasks. It separates reading, proposing and executing. It makes safe actions fast and risky actions deliberately slower.

The goal is not to make AI agents useless. The goal is to make the safe path the easy path.

A better architecture: execution as its own layer

The core idea is simple: the AI should not be the only gate between proposal and execution.

It can suggest an action. It can explain why the action makes sense. It can prepare parameters, describe expected effects and offer alternatives.

But between suggestion and execution, there should be a deterministic layer.

That layer can start very simply:

• allowed tools per agent and task;
• separate read and write permissions;
• no production writes without approval;
• blocked actions for irreversible operations;
• short-lived tokens instead of permanent secrets;
• pull requests instead of direct commits;
• staging before production;
• audit logs containing prompt, tool call, parameters, result and approval;
• cost and volume limits for API actions;
• alerts for unusual patterns.

In larger environments, this becomes policy-as-code: rules that are not just written in a document, but technically checked before execution.

For example:

An agent may analyse a database schema, produce a migration proposal and write tests. It may not run that migration against production. For that, the team needs a pull request, a successful test run, a backup, a review and explicit human approval.

Another agent may summarise support cases and prepare response drafts. It may not send messages to customers, change prices or copy personal data into an external system.

These distinctions are not bureaucracy. They are product quality.

What German companies should pay attention to

For German companies, several concerns meet in the same place: data protection, availability, traceability, customer trust and often quite complex legacy system landscapes.

Many mid-sized German companies do not have one clean platform. They have a mixture of ERP, CRM, Excel, specialist software, SaaS tools, manual approvals and historically grown interfaces. This is exactly where agents are tempting. They can bridge gaps, speed up processes and make internal tools easier to build.

But this is also where unclear tool access is especially dangerous.

If nobody has documented which system contains which data, which exports are sensitive or which API calls have side effects, an agent cannot magically make that complexity safe. It can only operate it faster.

That is why introducing agents should not begin with “which tool looks most impressive?”

It should begin with a sober system map:

• Which data is sensitive?
• Which systems are production-critical?
• Which actions are reversible?
• Which actions are expensive, legally relevant or customer-visible?
• Are backups and recovery processes tested?
• Which approvals already exist today?
• Which approvals need to be technically enforced?

Only after that does it make sense to decide which agent may handle which workflow.

The productive middle: limit, do not block

It would be wrong to conclude that companies should avoid AI agents because of these risks.

The opposite is more likely. Teams that integrate agents well will learn faster, ship faster and remove more internal friction.

But the winners will not be the teams that give every agent blanket access. The winners will be the teams that build good boundaries.

A sensible adoption path often looks like this:

1. Read-only mode: the agent analyses code, documentation, tickets, logs or data, but makes no changes.
2. Proposal mode: the agent creates pull requests, migration drafts, response drafts or process recommendations.
3. Limited execution: the agent may perform safe, reversible actions in clearly defined environments.
4. Approval-gated execution: risky actions require review, tests, backup and human approval.
5. Measurement and adjustment: logs, failures, costs and time savings are reviewed regularly.

Trust then comes from operating experience, not from hope.

The real advantage: better systems, not just faster work

AI-agent adoption is often discussed as a productivity topic. How much faster can we write code? How many tickets can we close? How much cheaper will development become?

Those are reasonable questions, but they are not enough.

The larger advantage appears when companies use agents as a reason to structure their systems better: clear APIs, clean roles, reliable tests, documented data flows, good deployment processes and traceable decisions.

Agents work best in environments that are also maintainable for humans.

If a system only stays stable because of informal knowledge, manual exceptions and “ask Anna, she knows”, an agent will eventually do something foolish there. If a system has clear boundaries and useful feedback, an agent can create real value.

This is where McDougall Digital usually starts: not with AI as a toy, but with AI-supported software development for serious products.

We help teams connect agents to architecture, delivery process and operations in a useful way. That includes tool and API boundaries, role models, CI/CD, tests, review flows, auditability and pragmatic security decisions that fit the company instead of slowing everything down unnecessarily.

Conclusion

AI agents need more than login credentials.

Once they can use tools, call APIs and change internal systems, authorization becomes a central architecture question. Who may execute what? Under which conditions? With which evidence? With which rollback path?

The good news is that this does not always require a huge enterprise programme. A strong first step is often enough: define agent roles, limit production writes, require approval for risky actions and make tool calls traceable.

If you want to use AI agents in development, internal tools or operational workflows, it is worth doing this work early.

McDougall Digital can help review existing workflows, design safe agent boundaries and set up AI-supported software delivery so that it is not only fast, but also maintainable in production.