Security by Design in AI and Software Projects | dynabase

Security by design means that security is planned in when a system is designed, not retrofitted after go-live. At dynabase, this is not an add-on service but part of every project, whether we build an AI agent, connect an interface or set up cloud infrastructure. Here we show which questions we answer along the way and what the implementation looks like in practice.

What does security by design mean?

If you only ask security questions at the end, you find gaps that are already built into the architecture. A service that was given admin rights for convenience at the start is hard to restrict later. That is why we clarify early on: who accesses which data? Which systems talk to each other? Where are passwords and keys stored?

Three principles help:

• Least privilege: every person, service and AI agent gets only the rights it needs for its task.
• Security by default: the secure setting is the default. More access is granted deliberately, not by accident.
• Privacy by design: data protection is planned in just as early, for example which data a system actually needs to store.

Security by design is not a certificate or a one-off checklist. It is a way of working that runs through design, development and operations.

Securing AI agents: what is the agent allowed to do?

An AI agent does more than answer questions. It retrieves data, uses interfaces and triggers actions in other systems. That makes the most important security question: what is the agent allowed to do, and what not?

We run several AI agents in our own daily work and have invested a lot of time in operating them securely. The biggest attack surface is almost always the tooling, meaning everything an agent can actually execute. That is why we pay attention to:

• Separate credentials per agent instead of shared admin accounts
• Clear scopes: the agent only sees the data and tools it needs for its task
• Self-hosted, isolated operation when sensitive data is involved
• Monitoring, so unusual behavior gets noticed
• Regular testing, for example for prompt injection (how we test our agents)

AI security follows the same rule as any other software: an agent is only as secure as the rights it is given. More on how we build agents: AI agent development.

APIs and interfaces: authentication, authorization and permission concept

For every interface, we ask two questions. First: who are you? That is authentication, for example via tokens based on the OAuth2 standard. Second: what are you allowed to do? That is authorization, and it is defined in the permission concept.

A permission concept defines which role may read, change or delete which data. An example: an AI agent that looks up inventory levels for the sales team needs read access to inventory. It does not need to change orders or see customer data, so it does not get those rights.

In practice, this means:

• Roles and rights are defined before development, not afterwards
• Every request is checked, including between internal systems
• Access is logged so it can be traced
• Your company's requirements go straight into the concept

More on interfaces and system integration: custom software development.

Cloud security and Kubernetes: who is allowed to talk to whom?

In the infrastructure, the same question comes up at a different level: which services may communicate with each other, and how do they get their credentials? With cloud security, many people think of the provider first. But a large part depends on how your own setup is configured.

• Network policies: we define which services may talk to each other. The frontend can reach the API, for example, but not the database directly.
• RBAC in Kubernetes: role-based rights for people and services in the cluster.
• Secrets management: passwords, keys and tokens are kept in a central store, not in the code. The application receives them at runtime, and they can be rotated regularly (secret rotation).
• Secure deployments: infrastructure as code and traceable deployments, so changes are reviewed and repeatable.
• Firewall rules: only the connections that are really needed are open.
• Audit logs and monitoring: access and anomalies become visible.

More on this: cloud infrastructure and DevOps.

Hybrid setups: connecting cloud and your own servers securely

Not every solution runs entirely in the cloud. For Hortiya, we connect our own servers, Google Cloud and IoT devices for greenhouse control. The QS Monitor for Mainzer Netze runs Kubernetes on the customer's own infrastructure. In setups like these, another question comes up: how are the sites connected securely? We solve this, for example, with VPN connections that only link the systems that need to talk to each other.

Including your company's requirements

Many companies have their own security policies, often derived from standards such as ISO 27001 or requirements such as NIS2. We clarify these requirements at the start of the project and build them into the architecture, permission concept and operations instead of ticking them off at the end. That way, the software we build meets your requirements from day one.

Conclusion

At dynabase, security by design is part of every project. The questions are always similar: who may do what, which systems talk to each other, and where are the credentials kept? The earlier they are answered, the less needs to be fixed later.

Planning a project
where security matters?

Let's talk in a free call
about what matters in your case.

Book a call

Frequently asked questions about security by design