Security & Trust Boundaries — MCP & Agent Interoperability

Security becomes clearer when you stop thinking of it as a wall and start thinking of it as a set of promises. A user promises to be who they claim to be. A service promises to handle data safely. A network promises to carry traffic without exposing it. A trust boundary is the place where one promise is no longer enough and a fresh check is needed.

Start with the idea of a boundary

A boundary is a line between two places with different rules. A locked office door is a boundary. So is the sign-in screen of an application, the edge of a cloud subscription, a database permission, or the point where one service calls another through an application programming interface (API).

A trust boundary is crossed whenever a person, device, service, or piece of data moves from one area of control into another. On one side, you may know who is present, what they can do, and how the system is configured. On the other side, you may know less. The boundary is where the system must ask, “What evidence do I have, and is it enough?”

This is different from a physical or network boundary. A firewall can be useful, but it is not the only line that matters. A request from inside a private network can still be dangerous. A request from the public internet can be safe if it is strongly authenticated, authorized, inspected, and logged.

Security boundaries and trust boundaries are not the same

A security boundary is a separation that is designed to withstand hostile action. If one side is compromised, the boundary should prevent the compromise from automatically taking over the other side. Examples include separate cloud tenants, separate operating system processes with strong isolation, and separate encryption keys controlled by different administrators.

A trust boundary is broader. It marks a change in assumptions. A web application and its database may sit inside the same private network, but they still have a trust boundary between them because the database should not trust every command merely because it came from the application server.

Confusing the two leads to weak designs. Teams may say, “It is on the internal network, so it is trusted.” That is an assumption, not a control. A better statement is, “This caller has a verified identity, has only the permissions needed for this operation, and every access is logged.”

Use security boundaries to contain compromise.
Use trust boundaries to decide where fresh verification is required.
Treat every cross-boundary call as a place to authenticate, authorize, validate, and log.
Document assumptions so they can be tested instead of inherited.

⚠️

Do not trust location. Network location can be one signal, but it should not be the main proof that a request is safe.

The basic question: who can do what to which thing

Most security decisions reduce to one sentence: a principal can perform an action on a resource under certain conditions. A principal is a user, device, workload, or service identity. A resource is something worth protecting, such as data, a secret, a model, a queue, or an administration setting.

Authentication answers, “Who or what is this?” Authorization answers, “What is this principal allowed to do?” Conditions answer, “Is this still allowed right now?” For example, a finance analyst may be allowed to read a report only from a managed device, only after multifactor authentication, and only during an approved session.

Microsoft Entra ID is commonly used to authenticate users, applications, and managed identities in Microsoft cloud environments. But the principle is not vendor-specific: identity should be explicit, permissions should be narrow, and authorization should be checked close to the resource.

Every access decision checks whether a principal may perform an action on a protected resource.

Data crosses boundaries too

People often draw boundaries around systems and forget that data moves more freely than systems do. A customer record may begin in a web form, pass through an API, enter a database, appear in a report, feed a machine learning model, and be exported to a support tool. Each move can change who can see it, copy it, infer from it, or delete it.

Good boundary design follows the data. Classify data by sensitivity, reduce unnecessary copies, encrypt data in transit and at rest, and keep separate keys or accounts for separate risk levels. Encryption is not magic; it protects against specific failures, such as stolen storage media or intercepted traffic, but it does not help if an authorized service is allowed to read and leak the data.

In systems built with Microsoft Foundry and Foundry Tools, the same question applies to prompts, retrieved documents, embeddings, outputs, evaluation data, and logs. Treat these as data assets, not as temporary text. A prompt can contain secrets. A response can contain regulated information. A log can become a hidden copy of sensitive data.

📌

Logs are data. If a log can contain personal, secret, or regulated information, it needs the same care as the system that produced it.

A single record moves through many systems, and each hop can change who may see it.

Trust should be earned repeatedly, not granted forever

Older designs often assumed that a user or service became trusted after signing in or joining a private network. Modern systems are too connected for that to be enough. Devices change state, credentials are stolen, services are updated, and attackers move laterally from one foothold to another.

The safer pattern is continuous verification. A system checks identity, device health, session risk, requested action, data sensitivity, and recent behavior. It does not mean asking the user to sign in every minute. It means using the right evidence at the right point, and stepping up the challenge only when risk justifies it.

Least privilege is the companion idea. Give each principal only the permissions needed, for only as long as needed. A build pipeline may need permission to deploy an application, but not to read all customer data. A support engineer may need temporary access to one case, not permanent access to every tenant.

Trust is earned continuously by re-checking identity, device, session, and action on each request.

Boundaries fail at the joins

Many incidents happen not because one control is absent, but because two controls do not meet cleanly. A service accepts a token but does not check the audience. A storage account is private but a backup copy is public. An application validates input at the browser but not at the server. A model is protected, but the retrieval index feeding it contains data from the wrong audience.

A token is a signed piece of data that carries claims about a principal and is used to request access. Tokens are powerful because they let systems avoid sending passwords around. They are dangerous when a receiving service accepts a token meant for some other service, ignores expiry, or trusts claims without validating who issued them.

Input validation is another join. Anything that crosses a boundary should be treated as untrusted until checked. That includes form fields, files, API requests, message queues, model outputs, configuration changes, and administrative commands.

Validate token issuer, audience, signature, expiry, and required claims.
Validate input on the server side, not only in the client.
Separate production, test, and development data unless there is a controlled reason to connect them.
Keep secrets out of source code, container images, prompts, and logs.
Test backup, export, and analytics paths as seriously as the main application path.

⚠️

Check the receiver. A boundary is only as strong as the service that receives the request and enforces the rule.

A token is only safe when the receiver checks that it was issued for this service and is still valid.

The leadership decisions are trade-offs, not slogans

Leaders and practitioners make boundary decisions every time they choose a tenant model, an identity pattern, a network design, a data retention policy, or an operations process. These choices affect cost, speed, user experience, incident containment, and regulatory exposure.

A single shared tenant may be simpler to operate, but separate tenants can create stronger administrative separation. A shared data platform may improve analytics, but it can also widen the blast radius of a mistaken permission. A highly locked-down environment may reduce risk, but if it blocks normal work, people will invent side channels that are worse.

The useful question is not “Is this secure?” in the abstract. It is “What failure are we trying to contain, what boundary contains it, who can cross that boundary, and what evidence proves they should be allowed?” That framing turns security from a vague approval step into an engineering and governance decision.

A practical way to map your boundaries

Start with a simple drawing. Put users, devices, applications, services, data stores, administrators, external partners, and monitoring systems on the page. Then draw a line anywhere ownership, identity, permission, network exposure, data sensitivity, or operational control changes.

For each line, name the check that happens there. If no check happens, write that down too. The absence of a check is not always wrong, but it should be a deliberate choice. Then ask what happens if one side is compromised. Can the attacker read more data, change policy, create accounts, mint tokens, disable logs, or move into another environment?

Finally, turn the map into a backlog. Add missing authentication, tighten authorization, reduce standing privileges, split duties, protect secrets, improve logging, and test recovery. Boundary work is never finished, but it becomes manageable when every improvement has a place on the map.

List the principals and resources.
Mark every place where control or sensitivity changes.
Name the verification performed at each boundary.
Identify what a compromise on either side would allow.
Prioritize fixes that reduce blast radius or improve evidence.

✅

Make it visible. A rough boundary map that teams can discuss is more useful than a perfect diagram no one maintains.

Key takeaways

A trust boundary is crossed whenever assumptions change and fresh verification is needed.
Security boundaries contain compromise; trust boundaries tell you where to authenticate, authorize, validate, and log.
Identity, permission, context, and resource sensitivity should be evaluated close to the resource being protected.
Data, prompts, outputs, and logs all cross boundaries and must be protected as real assets.
Least privilege and continuous verification reduce the damage caused by stolen credentials or compromised services.
Good boundary design is a leadership trade-off between simplicity, usability, cost, and containment.

Glossary

Trust boundary: A point where assumptions change and a system should perform a fresh check before allowing access or accepting data.
Security boundary: A separation designed to contain compromise so that control of one side does not automatically grant control of the other.
Principal: A user, device, workload, or service identity that can request access to a resource.
Authentication: The process of proving who or what a principal is.
Authorization: The process of deciding what an authenticated principal is allowed to do.
Least privilege: The practice of granting only the access needed for a specific purpose and no more.
Token: A signed piece of data that carries claims about a principal and is presented to request access.
Tenant: A dedicated identity and administration boundary for an organization or environment in a cloud service.
Managed identity: An identity assigned to a workload so it can access resources without storing a password or secret in code.