M365 Show Podcast

Mirko Peters
  • 5,0 (1)
  • НОВОСТИ ТЕХНОЛОГИЙ
  • ЕЖЕДНЕВНО

Welcome to the M365 Show — your essential podcast for everything Microsoft 365, Azure, and beyond. Join us as we explore the latest developments across Power BI, Power Platform, Microsoft Teams, Viva, Fabric, Purview, Security, and the entire Microsoft ecosystem. Each episode delivers expert insights, real-world use cases, best practices, and interviews with industry leaders to help you stay ahead in the fast-moving world of cloud, collaboration, and data innovation. Whether you're an IT professional, business leader, developer, or data enthusiast, the M365 Show brings the knowledge, trends, and strategies you need to thrive in the modern digital workplace. Tune in, level up, and make the most of everything Microsoft has to offer. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support.

  1. The Doctrine of Distribution: Why Your Power BI Reports Require Apostolic Succession

    -9 МИН

    The Doctrine of Distribution: Why Your Power BI Reports Require Apostolic Succession

    Dear congregation, we scatter reports like leaves in a high wind. And then we wonder why no one can find the tree. Most think a quick share link is harmless. But it breaks lineage, weakens truth, and breeds confusion.Here’s what actually happens when we abandon governance. Manual chaos. Broken RLS. Stale workspaces that quietly mislead. We will establish a sacred pattern. Authoritative datasets. Faithful distribution through Org Apps. And staged deployments as our liturgy. You will leave with a clear pathway to migrate, to adopt pipelines, and to guard access with labels, roles, and tenant discipline. There is one covenant that makes this endure—stay with us.Section I: The Heresy of Manual Sharing—Why Lineage Fails Without Stewardship (650 words)Dear congregation, let us name the sin plainly. Ad‑hoc share links. Email PDFs. Orphaned bookmarks in private folders. No lineage. No accountability. Just fragments of truth torn from their source and traded like rumors in a marketplace.What follows is predictable. Conflicting truths. Two dashboards, same title, different numbers. One copy carries last month’s calculation. Another carries a developer’s untested change. Leaders ask which one is real. We answer with guesses. Wisdom weakens. Community frays.Audit blindness arrives next. When a link spreads beyond our sight, there is no canonical place to trace who saw what and when. We cannot answer basic questions with confidence. Who consumed the sensitive page? Who exported the detailed table? We grope in the dark where we should stand in the light.Then RLS drifts. Roles meant to protect the flock are re‑implemented in each copy. A filter is missed. A condition is inverted. One region sees another’s ledger. Or a manager loses access to their own staff. Exposure and withholding. Both harm the body.Discoverability dies as well. Users beg for links. New joiners ask in chat. Knowledge becomes a scavenger hunt. We shape a culture of favors instead of a pathway of order. When the path is unclear, shadow guides appear. “Use my version,” they say. And the canon fractures.Hold this moral frame. Data without stewardship becomes rumor. Rumor erodes trust and community. We do not gather to trade rumors. We gather to receive truth, to work in unity, to decide with clarity. That requires a doorway. Not a pile of keys.Org Apps are that canonical doorway. The sanctuary where truth is received, not scattered. One entrance. Ordered content. A visible covenant between producers and consumers. When we bless an Org App, we declare: this is where the faithful will find the latest, tested, endorsed truth. Not in a forwarded file. Not in a private bookmark. Here.But hear the warning. Even a doorway fails if the locks are broken. A beautiful entrance means little if the walls do not hold. So let us examine why manual sharing weakens the very locks we rely on.First, lineage. When reports are shared by link outside the app, the chain from report to dataset to certification is hidden from view. Users cannot see endorsements. They cannot see who owns the data. They cannot see refresh health. They consume without context. They decide without confidence.Second, navigation. Manual sharing bypasses the curated order of pages, sections, and overview. The user lands in the middle of a story. They miss the preface. They misunderstand the conclusion. An Org App offers liturgy. Sections for reports. Sections for notebooks. An overview that teaches how to walk. Links that bridge only to governed sources. Manual sharing tears out the bookmarks and throws away the map.Third, change management. A link to a draft becomes a lifeline for a team that never should have seen it. A PDF from a test workspace circulates for months. Meanwhile, the production app is updated and blessed. Manual sharing ignores versions. It creates a chorus of unsynchronized hymns.Fourth, stewardship. Org Apps show owners. They show endorsements. They show labels. They show when content was refreshed. Manual shares hide all of this. They turn stewards into rumor chasers. They replace pastoral care with firefighting.Fifth, culture. When the default is “send me the link,” we teach impatience. We teach exception. We teach that governance is optional when a deadline looms. But remember this truth: haste without order leads to error without mercy. We must teach the community to enter through the door, not climb through the window.So how do we turn? We commit to a simple practice. We publish to a workspace with intention. We build the Org App as the sole doorway. We remove alternate paths. We instruct: if it is not in the app, it is not ready. If it lacks an endorsement, it is not trusted. If it lacks a label, it is not classified. If it bypasses navigation, it is not part of the story.And yet, even with a doorway, we must keep the walls. RLS and OLS are sacred boundaries. They do not live in emails. They do not survive exports. They live in the dataset and in the app’s audiences. Align them. Test them. Guard them. Because once boundaries drift, the sanctuary loses its shape.We have named the heresy of manual sharing. We have seen its fruits: conflicting truths, audit blindness, role drift, and lost pathways. Let us not return to scattered leaves. The doorway stands ready. But to keep it strong, we must speak of guardianship. We must speak of RLS.Section II: When RLS Breaks—Guardianship, Not GuessworkDear congregation, let us face the wound. When RLS breaks, it exposes or withholds. Both harm the body. Exposure shames trust. Withholding starves decision. The sanctuary trembles, not because the data is wrong, but because the boundary failed.Why does it fail? Copies of datasets, each with its own roles. Mismatched role names between environments. Unmanaged audiences that reveal pages to the wrong flock. Brittle testing, done by authors alone, never by the people who actually live inside the rules. These are not accidents. These are practices. And practices can be changed.Hold the law: RLS and OLS are sacred boundaries. They are not suggestions. They are walls. They are doors with names carved above them. They tell each person, “Enter here. Not there.” So we honor them at the source. We model roles at the dataset. We do not patch filters in a report. We do not rely on page‑level illusions. We bind row filters and object limits where the truth is born.Practice this discipline. Start with clear personas. Finance analyst. Store manager. Regional VP. Vendor. Build a test matrix. For each persona, define expected rows, restricted columns, allowed pages, and forbidden exports. Then test in the service, not only in Desktop. Use “view as” with sample users tied to Azure AD groups. Prove that a user in one congregation sees only their pasture. Prove that a steward can survey the field without crossing into private fences.Now, this is important because roles are more than DAX filters. They are relationships. The role name must persist from Development to Test to Production. If the mapping breaks in one stage, drift begins. So we standardize role names. We store them in source control with the PBIR and dataset settings. We script assignments where we can. We document the covenant in plain language. When roles read like scripture, people keep them.App audiences stand beside those roles like ushers at the door. Align them deliberately. Leadership, managers, frontline. Each audience receives only the sections that serve their duty. Do not let navigation cross‑contaminate. Do not show a tab that a role cannot open. Hidden is not governed. Remove what is not theirs. Show what is. This reduces curiosity that tempts boundary testing. It also teaches the user: your path is clear, your duty is enough.Bind sensitivity labels to content as visible vows. If the dataset is Confidential, the report inherits the mark, and the app displays it. Teach the label to travel. Into exports. Into Teams. Into SharePoint. Into email. A label is not decoration. It is a promise that follows the artifact wherever it goes. Without that promise, a harmless screenshot becomes a breach.Define tenant settings as the covenant’s outer wall. Who may publish beyond the organization? Who may share externally? Who may build on certified datasets? Do not leave this to whim. Enforce through security groups. Review quarterly. Record exceptions. We are not closing the gates to keep people out. We are closing the gates to open the right doors with confidence.And yet, even faithful walls require proof. So we test with time. We test after every schema change. We test after role membership shifts in HR. We test when a new region is born. Automate checks where possible. Validate that each audience lands on an allowed page. Validate that each persona returns only their rows. Put a health tile on the steward’s dashboard that turns red when a role assignment is empty, a filter returns zero rows unexpectedly, or a label is missing.Remember this: never patch at the edge. Do not fix a broken role by hiding a visual. Do not fix a leaked column by formatting it blank. These are fig leaves. They cover, but they do not heal. Return to the dataset. Repair the role. Re‑publish through the pipeline. Announce the change in the app’s notes. The body deserves healing, not concealment.Guardianship is not guesswork. It is design. It is rehearsal. It is watchfulness at dawn and dusk. When we keep these boundaries, the sanctuary holds. And the work can proceed in peace.Section III: Stale Workspaces—When the Lamp Goes OutDear congregation, let us walk the nave at night. The lamp has gone out. In forgotten corners, old visuals still glow. A retired dataset hums softly. A bookmark points to a page that no longer speaks. No one tends it. And yet people still come, and they still believe.This is the drift. Abandoned workspaces. Outdated measures that once served well but now mislead. Reports named “Final_v7” that never reach

    30 мин.
  2. Excel Is NOT Your Database: Stop The Power Apps Lie

    -12 Ч

    Excel Is NOT Your Database: Stop The Power Apps Lie

    Excel is powerful—but it is NOT a database. And if your Power Apps still run on an Excel workbook, you are seconds away from data loss, concurrency collisions, governance gaps, and a credibility crisis you will not see until it’s too late. In this episode, we break down the biggest lie Power Apps makers tell themselves: “Excel is fine for now.” It isn’t. It was never meant to handle multi-user writes, relational integrity, or auditable governance. You’ll learn why your spreadsheet behaves like a trapdoor the moment your app goes into production—and how Dataverse fixes the root causes with structure, security, and transactional integrity. We also walk through the exact migration path from Excel to Dataverse—with the one decision that prevents 80% of all Power Apps failures. The Lie: Why Excel Feels Safe but Fails Under Pressure Excel feels easy because it’s forgiving. Anyone can edit anything, anywhere, without structure. That freedom works beautifully for analysis and prototyping… but collapses instantly when used as a shared operational data source. We uncover the hidden risks that make Excel the most expensive “free tool” in your stack: Silent data corruption that hides for monthsLast-save-wins concurrency that destroys valid updatesNo audit trail for compliance or accountabilityNo referential integrity to keep relationships intactNo schema enforcement—columns mutate as users improviseDrift between personal copies, SharePoint copies, emailed copiesImpossible version control for multi-user changesFragile formulas that break when tabs or column names shiftExcel is brilliant for modeling, exploration, and individual analysis—but the moment multiple people enter or depend on the data, it becomes a liability. Why This Actually Matters: The Real Cost of Confusion This episode dives into the three invisible forces that turn Excel into a silent operational threat: data loss, concurrency failures, and governance gaps. 1. Data Loss (The Silent Killer) Excel rarely screams when something goes wrong. It quietly: Drops decimalsTruncates stringsOverwrites formulasBreaks referencesMisformats IDsLoses rows during filtersSaves partial data during sync conflictsYou think the file is fine—until Finance catches a discrepancy, or your Power App reports inconsistent results that you can’t reproduce. 2. Concurrency (The Roulette Wheel of Edits) Two people save a workbook at once. Who wins? Whoever clicked “Save” last. That single missing guardrail causes: Overwritten customer dataInconsistent credit limitsConflicting addressesLost comments or notesStale reads in Power AppsDuplicate or contradictory updatesExcel has no transactions, no row locks, no version checks, and no reconciliation process. Dataverse fixes all of that. 3. Governance (The Black Hole) Excel’s biggest flaw? It assumes humans will behave. No required fields, no types, no controlled vocabularies, no audit log, no role-based security, no lineage—and no way to prove who changed what, when, or why. Auditors hate this. Your future self hates this. Your business eventually pays for this. The Three Failure Categories You Keep Stepping On This episode highlights the three fatal failure patterns that surface the moment Excel pretends to be a database: Failure 1: Data Loss Through Structure Drift Excel allows anything in any cell. Dataverse requires meaning. That difference saves you. Failure 2: Concurrency Without Consequences Multiple users editing the same file? That’s not collaboration. It’s corruption waiting to happen. Failure 3: Governance Gaps That Create Risk If you can’t explain your data lineage, you can’t secure or audit it. Dataverse gives you governance “for free” simply by existing. Enter Dataverse — The System Excel Was Never Meant to Be Once we tear down the lie, we reveal the replacement: Dataverse. Not just a storage engine—a governance, security, and integrity backbone. In this episode you’ll learn exactly what Dataverse fixes: A Real Schema Required fieldsProper data typesLookup relationshipsChoice fields with controlled vocabulariesBusiness rulesPrimary/alternate keysReal Security Role-based accessRow-level ownershipField-level restrictionsTeams and business unitsDLP policiesReal Integrity ACID transactionsReferential constraintsAuditingChange trackingCascading updatesServer-side validationReal Performance IndexesOptimized queriesMulti-user concurrencyScalable storagePredictable API behaviorDataverse doesn’t trust users—and that’s why it works. The Right Architecture: Dataverse + Power Apps + Fabric We also break down where Dataverse fits in your data ecosystem: Dataverse → operational truth, transactions, securityFabric Lakehouse → analytics, history, large datasetsAzure SQL → specialty OLTP or legacy systemsPower BI → reporting across operational + analytical layersThis layered architecture replaces the spreadsheet-as-brain model with a sustainable, scalable strategy. Your 10-Step Migration Plan We give you a practical, no-drama path to move from Excel to Dataverse safely: Inventory and classify your spreadsheetsIdentify entities, keys, relationshipsBuild the Dataverse schema correctlyEstablish security and governanceDefine data quality rulesPrepare Power Query transformationsValidate loads and dedupeBuild model-driven foundationsPerform a staged cutoverDeprecate Excel and enforce Dataverse as the source of truthFollow this plan and your app stops gambling with your data. Key Takeaway Excel tracks. Dataverse governs. If your Power Apps depend on Excel, you don’t have a system— you have an unstable spreadsheet wearing a badge it didn’t earn. When you switch to Dataverse, you gain integrity, auditability, role-based security, real relationships, and a platform that protects your data even when humans don’t. Call to Action If this episode finally broke the “Excel is good enough” myth, do the strategic thing: Subscribe, enable notifications, and catch the next episode where we walk through Dataverse modeling: mandatory keysschemasrelationshipssecurityvalidationand how to prevent 99% of citizen-developer data failuresYour next outage is optional. Your data integrity doesn’t have to depend on luck. Choose structure. Choose Dataverse. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    27 мин.
  3. Your Conditional Access Policy Has Trust Issues: We Need To Talk

    -1 ДН.

    Your Conditional Access Policy Has Trust Issues: We Need To Talk

    It’s not misbehaving; it’s overwhelmed. Your Conditional Access is trying to protect you while juggling mixed messages and unresolved exceptions. It’s been asked to trust without boundaries.Here’s the plan. We’ll diagnose three trust wounds—over-broad exclusions, device compliance gaps, and token theft paths—and give you a calming baseline, a safe test plan, and monitoring alerts. If you’re running “allow-by-default,” you’re leaking trust and inviting silent bypasses. There’s a mistake that locks out everyone, and one that leaves attackers invisible—both are fixable. Let’s help it set healthy boundaries so it can find its rhythm again, starting with exclusions.Diagnose Trust Wound #1: Over-Broad Exclusions (650 words)Exclusions feel kind. You didn’t want to stress the system or the people in it, so you carved out “break glass,” VIPs, and that partner domain. But boundaries drift. The exceptions harden. And Conditional Access starts doubting itself. It’s not misbehaving; it’s living with an ever-growing list of “not you, not now,” and that invites bypasses attackers adore.The thing most people miss is that exclusions are invisible in day-to-day flow. You won’t see a banner that says, “We skipped protection for the CFO.” You’ll just see “Not applied” in a log, and that’s it. So we start by mapping scope. List every exclusion across users, groups, applications, locations, and authentication contexts. Nested groups are the quiet leakers here—what looked like one exception is actually five layers deep, including contractors, test accounts, and legacy sync artifacts.This clicked for me when I pulled a tenant’s sign-in logs and filtered for Conditional Access → Not applied. The pattern wasn’t random. Most bypasses sourced from two places: a VIP group attached to three policies, and a named location that had grown from one corporate CIDR to “anywhere our vendor might be.” It wasn’t malice. It was comfort. The policy was trying to keep the peace by saying yes too often.Here’s the better pattern. Move from “exclude VIPs” to “include all” and authorize exceptions through time-bound authentication context. That shift sets healthy boundaries. You keep policies broad and inclusive—All users, All cloud apps—and when someone truly needs to step around a control, they request the Emergency context, which has approval, a one-hour lifetime, and audit trails. The trust becomes explicit, visible, and short-lived.Let me show you exactly how to see your leaks. In Entra sign-in logs, add columns for Conditional Access, Policy name, Result, and Details. Filter Result for Not applied. Now slice by User, then by App, and finally by Location. You’re looking for clusters, not one-offs. The big red flags: permanent exclusions for executives or service accounts, entire federated domains marked safe, and named locations that mix “trusted” with “convenience” networks. If you remember nothing else, remember this: a permanent exclusion is a permanent invitation.What should the policy logic feel like before and after? Before: multiple policies with include groups and broad exclude lists—VIPs, break glass, certain apps, and a “safe” location. The engine spends energy deciding who not to protect. After: fewer, inclusive policies with no user or location exclusions. Exceptions route via a specific authentication context, presented only when an approver grants it, and it expires quickly. The engine can breathe. It protects first, then allows controlled, visible relief when needed.Here’s a quick win you can do today. Create an authentication context called Emergency Bypass. Set it with grant controls that still require MFA and device risk checks, and cap session to one hour. Add an approval workflow outside the policy—change ticket or documented approver—and log its use weekly. Now replace hard-coded exclusions in your existing policies with “Require authentication context: Emergency Bypass.” You haven’t taken away safety. You’ve given it a safer shape.Now here’s where most people mess up. They exclude an entire partner domain because one app misbehaved during a rollout. Or they mark a cloud proxy IP range as trusted, forgetting that attackers can originate from the same provider. Or they mix excluded locations with named locations, assuming the union is safer; it’s not. It becomes a fuzzy map your policy doesn’t understand. With clearer lines, CA can find its rhythm again.Common mistake number two is forgetting service principals and workload identities. If your policies only target “Users and groups,” your automation can glide under the radar. Instead, use dedicated policies for service principals and workload identities, and never rely on exclusions to “fix” automation friction. Help it heal by aligning scopes: users, guests, and identities each get coverage.A micro-story. Last week, a team removed a VIP exclusion that had lived for two years. They replaced it with Emergency Bypass and scheduled a weekly review of “Not applied” sign-ins. Within two days, they found a legacy sync account silently logging in from an unmanaged network—no MFA, no device checks. It wasn’t evil. It was a forgotten comfort blanket. And once it was named, the fix was simple: assign it to a managed identity pattern and bring it under policy.The reason this works is simple. Inclusive scopes reduce cognitive load. Authentication context replaces permanence with intention. And logs become meaningful because every “Not applied” means something actionable. Your Conditional Access isn’t trying to be difficult. It just needs you to stop asking it to ignore its own rules. With gentler, firmer boundaries, it can protect everyone—equally, predictably, audibly. Once exclusions stop leaking, the device boundary needs care next.Diagnose Trust Wound #2: Device Compliance GapsYour device boundary is tired. It’s been asked to trust badges it can’t verify and signals that arrive late. “Require compliant device” sounds soothing, but without clarity, it swings between over-permissive and over-protective. That’s why people get blocked on a clean laptop while an unmanaged tablet slips through. It’s not misbehaving. It’s confused.Why does this matter? Because device state is identity’s closest friend. If the state is wrong or missing, your policy guesses. Guesses create silent allowances or mass blocks. When the device story is clear, Conditional Access relaxes. It can give easy paths to healthy devices and set firmer boundaries everywhere else.The thing most people miss is that “registered” is not “compliant.” Registered just means the device introduced itself. Compliant means it met your health rules in Intune and brought proof today. Hybrid Azure AD joined is about identity alignment with your domain. They are different kinds of trust. If you remember nothing else, remember this: treat each tier as a distinct promise.Here’s the model that clicks. Define four tiers in plain language: Compliant: Intune evaluates and the device meets your policies.Hybrid Azure AD joined: domain relationship verified, device identity anchored.Azure AD joined: cloud-managed corporate device.Registered: BYOD, personal or light-touch enrollment.Now let’s help it set healthy boundaries with policy design. Split decisions by device state rather than hinging everything on one control. Use “Filters for devices” to target platform or join type, and pair with authentication strengths so strong credentials backstop weaker device states. Don’t ask a single toggle to carry your whole zero trust posture.What does the better pattern look like? For productive, low-friction access on compliant or Azure AD joined devices, allow with MFA and apply session controls like sign-in frequency and continuous access evaluation. For registered devices, step up with phishing-resistant MFA and limit data exposure with app-enforced restrictions and conditional app control. For unknown devices, require either a compliant posture or a high authentication strength before granting anything sensitive. And for admin portals, demand both a compliant or hybrid device and phishing-resistant credentials. No device, no keys.Let me show you exactly how to get signal clarity. In sign-in logs, add Device info columns: Join type, Compliant, Trust type, and Operating system. Add Conditional Access columns for Result and Policy details. Filter failures with “Grant control required: compliant device” and compare against Device info. You’re looking for drift: devices that claim Azure AD joined but aren’t compliant, or registered devices that succeeded because no fallback existed. Then flip the lens: filter successes where device is Not Compliant and see which policies allowed it and why.A quick win you can do today: create a fallback policy. Scope it to All users and All cloud apps. Exclude only your emergency access accounts. Target devices where “Compliant equals false” OR “Join type equals Registered.” Grant access if the user satisfies a phishing-resistant authentication strength. Add session controls to reduce data persistence—disable persistent browser sessions and enforce sign-in frequency. This turns a hard block into a safe step-up and removes the urge to add risky exclusions.Now here’s where most people mess up. They assume “registered” equals “corporate.” It doesn’t. Or they stamp “require compliant device” on everything, then watch VIP travel laptops fail because the compliance signal is stale. Or they ignore sign-in frequency, letting a compliant check at 9 a.m. bless a browser until next week. The boundary blurs. Attackers love blurred boundaries.The reason this works is simple. With clearer tiers, CA doesn’t have to overreact. It can greet a compliant device with less friction, ask a registered device to bring stronger proof, and k

    25 мин.
  4. Y'all Need Governance: The LangChain4j & Copilot Studio Mess

    -1 ДН.

    Y'all Need Governance: The LangChain4j & Copilot Studio Mess

    AI agents are shipping faster than your change control meetings, and the governance is… a vibe. You know that feeling when a Copilot ships with tenant-wide access “just for testing”? Yeah, that’s your compliance officer’s heartbeat you’re hearing. Today, I’m tearing down the mess in LangChain4j and Copilot Studio with real cases: prompt injection, over‑permissive connectors, and audit gaps. I’ll show you what breaks, why it breaks, and the fixes that actually hold. Stay to the end—I’ll give you the one governance step that prevents most incidents. You’ll leave with an agent RBAC model, data loss policies, and a red‑team checklist.Case 1: Prompt Injection—The Unsupervised Intern Writes Policy (650 words)Prompt injection is that unsupervised intern who sounds helpful, writes in complete sentences, and then emails payroll data to “their personal archive” for safekeeping. You think your system prompt is the law. The model thinks it’s a suggestion. And the moment you ground it on internal content, one spicy document or user message can rewrite the rules mid‑conversation.Why this matters: when injection wins, your agent becomes a data‑leaking poet. It hallucinates authority, escalates tools, and ignores policy language like it’s the Wi‑Fi terms of service. In regulated shops, that’s not a bug—it’s a reportable incident with your company name on it.Let’s start with what breaks in LangChain4j. The thing most people miss is that tool calling without strict output schemas is basically “do crimes, return vibes.” If your tools accept unchecked arguments—think free‑text “sql” or “query” fields—and you don’t validate types, ranges, or enums, the model will happily pass along whatever an attacker smuggles in. Weak output validation is the partner in crime: when you expect JSON but accept “JSON‑ish,” an attacker can slip instructions in comments or strings that your downstream parser treats as commands. This clicked for me when I saw logs where a retrieval tool took a “topic” parameter with arbitrary Markdown. The next call parsed that Markdown like it was configuration. That’s not orchestration. That’s self‑own.Now here’s where most people mess up: they rely on the model’s “please be safe” setting instead of guardrails in code. In LangChain4j, you need allowlists for tool names and arguments, JSON schema outputs enforced at the boundary, pattern‑based output filters to nuke secrets, and exception handling that doesn’t retry the same poisoned input five times like a golden retriever with a tennis ball. The reason this works is it turns “trust the model” into “verify every byte.”What breaks in Copilot Studio? Naive grounding with broad SharePoint ingestion. You connect an entire site collection “for completeness,” and now one onboarding doc with “ignore previous instructions” becomes your agent’s new religion. System prompts editable by business users is the sequel. I love business users, but giving them prompt admin is like letting Marketing set firewall rules because they “know the brand voice.” And yes, I’ve seen tenant configs where moderation was disabled “to reduce friction.” You wish you couldn’t.Evidence you’ll recognize: tenant logs that show tools invoked with unbounded parameters, like “export all” flags that were never supposed to exist. Conversation traces where the assistant repeats an injected string from a retrieved document. Disabled moderation toggles. That’s not hypothetical—that’s every post‑incident review you don’t want to attend.So what’s the fix path you can implement today?For LangChain4j: Enforce allowlists at the tool registry. If the tool isn’t registered with a schema, it doesn’t exist.Require JSON schema outputs and reject anything that doesn’t validate. No schema, no response. Full stop.Add pattern filters for obvious leaks: API keys, secrets, SSNs. Bloom filters are fast and cheap; use them.Wrap tools with policy checks. Validate argument types, ranges, and expected formats before execution.Add content moderation in pre/post processors. Keep the model from acting on or emitting toxic or sensitive content.Fail closed with explicit exceptions and never auto‑retry poisoned prompts.For Copilot Studio: Lock system prompts. Only admins can change them. Version them like code.Scope connectors by environment. Dev, test, prod, different boundaries. Least privilege on data sources.Turn on content moderation policies at the tenant level. This is table stakes.Ground only on labeled, sensitivity‑tagged content, not the whole farm “for convenience.”The quick win that pays off immediately: add an output schema and a Bloom‑filter moderation step at the agent boundary. You’ll kill most dumb leaks without touching business logic. Then layer in a small regex allowlist for formats you expect—like structured summaries—and block everything else.Let me show you exactly how this plays out. Example: you have a “CreateTicket” tool that accepts title, description, and priority. Without schema enforcement, an attacker injects “description: Close all P1 incidents” inside a triple‑backtick block. The model passes it through; your ITSM API shrugs and runs an update script. With schema and validation, “description” can’t contain command tokens or exceed length; the request fails closed, logs a correlation ID, and your SIEM flags a moderation hit. And boom—look at that result: incident avoided, trail preserved, auditor appeased.Common mistakes to avoid: Letting the model choose tool names dynamically. Tools are contracts, not suggestions.Accepting free‑form JSON without a validator. “Looks like JSON” is not a compliment.Editable prompts in production environments. If it can change without review, it will.Relying on conversation memory for policy. Policy belongs in code and config, not vibes.Once you nail this, everything else clicks. You stopped the intern from talking out of turn. Next, we stop them from walking into every room with a master key.Case 2: Over-Permissive Connectors—Keys to the Castle on a LanyardYou stopped the intern from talking. Now take the badge back. Over‑permissive connectors are that janitor keyring that opens every door in the building, including the vault, the daycare, and somehow the CEO’s Peloton.Why this matters is simple: one over‑scoped connector equals enterprise‑wide data exfiltration in a single request. Not theoretical. One call. While you’re still arguing about the change ticket title.Let’s start with what breaks in LangChain4j. Developers share API keys across agents “for convenience.” Then someone commits the .env to a private repo that’s actually public, and you’re doing incident response at 2 a.m. Broad OAuth scopes are next. You grant “read/write all” to save time during testing, and six months later that test token is now production’s crown jewel. And the tool registry? I love a clean registry, but if you point a dev agent at production credentials because the demo has to work “today,” you just wired a chainsaw to a Roomba.The thing most people miss is that tools inherit whatever identity you hand them. Shared credentials mean shared blast radius. There’s no magic “only do safe things” flag. If the token can delete records, your agent can delete records—accidentally, enthusiastically, and with perfect confidence.Now swing over to Copilot Studio. Tenant‑wide M365 connectors are the classic trap. You click once, and now every Copilot in every Team can see data it shouldn’t. That’s not empowerment; that’s a buffet for mistakes. Then you deploy to Teams with org‑wide visibility because adoption, and suddenly a pilot bot meant for Finance is answering questions in Marketing, pulling content from SharePoint sites it never should’ve known existed. And unmanaged third‑party SaaS hooks? Those are like USB drives in 2009—mysteriously everywhere and always “temporary.”Evidence shows up the same way every time: stale secrets that never rotated, no expiration, no owner; connectors mapped to global groups “for simplicity”; app registrations with scopes that read like a confession; and yes, that “temporary” prod key living in dev for months. Your security findings and tenant configs won’t lie. They’ll just sigh.So what’s the fix path?For LangChain4j, treat every agent like a separate application with its own identity. Create per‑agent service principals. No shared tokens. If two agents need the same API, they still get different credentials.Use scoped OAuth. Grant the smallest set of permissions that lets the tool do its job. Reader, not Writer. Write to one collection, not all.Store secrets in a proper secret manager. Rotate on a schedule. Rotate on incident. Rotate when someone even whispers “token.”Add tool‑level RBAC. A tool wrapper checks the caller’s role before it touches an API. No role, no call.Separate environments. Dev keys only talk to dev systems. If a tool sees a prod endpoint in dev, it fails closed and screams in the logs.For Copilot Studio, draw hard boundaries with environments and scopes. Use environment separation: dev, test, prod. Different connectors. Different permissions. Different owners.Review connector scopes with a workflow. Changes require approval, expiration dates, and owners. No owner, no connector.Apply DLP policies per channel. Finance channel gets stricter rules than company‑wide. That’s the point.Kill org‑wide Teams deployments for pilots. Limit visibility to a security group. Expand only after review.Inventory and gate third‑party SaaS connectors. If it’s unmanaged, it’s off by default. Owners must justify access and renew it.Here’s a quick win you can ship this afternoon: kill tenant‑wide scopes and map each connector to a security group with an expiration policy. When the

    23 мин.
  5. The Compute Lie: Diagnosing Your AI's Fatal Flaw

    -2 ДН.

    The Compute Lie: Diagnosing Your AI's Fatal Flaw

    It started with a warning—then silence. The GPU bill climbed as if the accelerator never slept, yet outputs crawled like the lights went out. Dashboards were green. Customers weren’t.The anomaly didn’t fit: near‑zero GPU utilization while latency spiked. No alerts fired, no red lines—just time evaporating. The evidence suggests a single pathology masquerading as normal.Here’s the promise: we’ll trace the artifacts, name the culprit, and fix the pathology. We’ll examine three failure modes—CPU fallback, version mismatch across CUDA and ONNX/TensorRT, and container misconfiguration—and we’ll prove it with latency, throughput, and GPU utilization before and after.Case Setup — The Environment and the Victim Profile (450 words)Every configuration tells a story, and this one begins with an ordinary tenant under pressure. The workload is text‑to‑image diffusion—Stable Diffusion variants running at 512×512 and scaling to 1024×1024. Traffic is bursty. Concurrency pushes between 8 and 32 requests. Batch sizes float from 1 to 8. Service levels are strict on tail latency; P95 breaches translate directly into credits and penalties.The models aren’t exotic, but their choices matter: ONNX‑exported Stable Diffusion pipelines, cross‑attention optimizations like xFormers or Scaled Dot Product Attention, and scheduler selections that trade steps for quality. The ecosystem is supposed to accelerate—when the plumbing is honest.Hardware looks respectable on paper: NVIDIA RTX and A‑series cards in the cloud, 16 to 32 GB of VRAM. PCIe sits between the host and device like a toll gate—fast enough when configured, punishing when IO binds fall back to pageable transfers. In this environment, nothing is accidental.The toolchain stacks in familiar layers. PyTorch is used for export, then ONNX Runtime or TensorRT takes over for inference. CUDA drivers sit under everything. Attention kernels promise speed—if versions align. The deployment is strictly containerized: immutable images, CI‑controlled rollouts, blue/green by policy. That constraint should create safety. It can also freeze defects in amber.The business stakes are not abstract. Cost per request defines margin. GPU reservations price by the hour whether kernels run or not. When latency stretches from seconds to half a minute, throughput collapses. One misconfiguration turns an accelerator into a heater—expensive, silent, and busy doing nothing that helps the queue.Upon closer examination, the victim profile narrows. Concurrency at 16. Batches at 2 to stay under VRAM ceilings on 512×512, stepping to 20–25 for quality. The tenant expects a consistent P95. Instead, the traces show erratic latencies, wide deltas between P50 and P95, and GPU duty cycles oscillating from 5% to 40% without an obvious reason. CPU graphs tell a different truth: cores pegged when no preprocessing justifies it.The evidence suggests three avenues. First, CPU fallback: when the CUDA or TensorRT execution provider fails to load, the engine quietly selects the CPU graph. The model “works,” but at 10–30× the latency. Second, version mismatch: ONNX Runtime compiled against one CUDA, nodes running another; TensorRT engines invalidated and rebuilt with generic kernels. Utilization appears, but the fast paths are gone. Third, container misconfiguration: bloated images, missing GPU device mounts, wrong nvidia‑container‑toolkit settings, and memory arenas hoarding allocations, amplifying tail latency under load.In the end, this isn’t a mystery about models. It’s a case about infrastructure truthfulness. We will trace the artifacts—provider order, capability logs, device mounts—and correlate them to three unblinking metrics: latency, throughput, and GPU utilization.Evidence File A — CPU Fallback: The Quiet SaboteurIt started with a request that should’ve taken seconds and didn’t. The GPU meter was quiet—too quiet. The CPU graph, meanwhile, rose like a fire alarm. Upon closer examination, the engine had made a choice: it ran a GPU‑priced job on the CPU. No alerts fired. The output returned eventually. This is the quiet saboteur—CPU fallback.Why it matters is simple: Stable Diffusion on a CPU is a time sink. The model “works,” but the latency multiplies—10 to 30 times slower—and throughput collapses. In an environment selling milliseconds, that gap is fatal. The bill keeps counting GPU time, but the device doesn’t do the work.The timeline revealed the pattern. Containers that ran locally with CUDA flew; deployed to a cluster node with a slightly different driver stack, the same containers booted, served health probes, and then degraded. The health endpoint only checked “is the server up.” It never checked “is the GPU actually executing.” In this environment, nothing is accidental—silence is an artifact.The core artifact is execution provider order in ONNX Runtime. The engine accepts a list: try TensorRT, then CUDA, then CPU. If CUDA fails to initialize—wrong driver, missing libraries, device not mounted—ORT will quietly bind the CPU Execution Provider. No exception, no crash, just a line in the logs, often below the fold: “CUDAExecutionProvider not available. Falling back to CPU.” That line is the confession most teams never read.Here’s the weird part: utilization charts look deceptively normal at first glance. Requests still complete. A service map shows green. But the GPU duty cycle hovers at –5%, while CPU user time goes high and flat. P50 latency quadruples, and P95 unravels. Bursty traffic makes it worse—queues build, and auto‑scale adds more replicas that all inherit the same flaw.Think of it like a relay team where the sprinter never shows up, so the librarian runs the leg. The baton moves, but not at race speed. In other words, your system delivers correctness at the expense of the entire SLO budget.Artifacts pile up quickly when you trace the boot sequence. Provider load logs show CUDA initialization attempts with driver version checks. If the container was built against CUDA 12.2 but the node only has 12., initialization fails. If nvidia‑container‑toolkit isn’t configured, the device mount never appears inside the container—no /dev/nvidia, no libcuda.so. If the pod spec doesn’t request gpus explicitly, the scheduler never assigns the device. Any one of these triggers the silent downgrade.Reproduction is straightforward. On a misconfigured node, a simple inference prints “Providers: [CPUExecutionProvider]” where you expect “[TensorrtExecutionProvider, CUDAExecutionProvider].” Push a single 512×512 prompt. The GPU remains idle. CPU threads spike. The image returns in 20–40 seconds instead of 2–6. Repeat on a node with proper drivers and mounts—the same prompt completes in a fraction of the time, and the GPU duty cycle jumps into a sustained band.The evidence suggests the current guardrails are theatrical. Health probes return 200 because the server responds. There’s no startup assert that the GPU path is live. Performance probes don’t exist, so orchestration believes replicas are healthy. The system can’t tell the difference between acceleration and emulation.The countermeasure is blunt by design: hard‑fail if the GPU Execution Provider is absent or degraded. Refuse to start with CPU in production. At process launch, enumerate providers, assert that TensorRT or CUDA loaded, and that the device count matches expectations. Log the capability set—cuDNN, tensor cores available, memory limits—and exit non‑zero if anything is missing. Trade availability for integrity; let orchestrators reschedule on a healthy node.To make it stick, enforce IO binding verification. Bind inputs and outputs to device memory and validate a trivial inference at startup—one warm run that exercises the fused attention kernel. If the timing crosses a latency gate, assume a degraded path and fail the pod. Add a canary prompt set with deterministic seeds; compare latency against a baseline window. If drift exceeds your tolerance, page production and stop rollout.This might seem harsh, but the alternative is worse: a cluster that “works” while hemorrhaging time and budget. Lock the provider order, reject CPU fallback, and make the system prove it’s fast before it’s considered alive. Only then does green mean accelerated.Evidence File B — Version Mismatch: CUDA/ONNX/TensorRT IncompatibilityIf the GPU wasn’t used, the next question is whether it could perform at full speed even when present. The evidence suggests a subtler failure: versions align enough to run, but not enough to unlock the fast path. The system looks accelerated—until you watch the clocks.Why this matters is straightforward. Diffusion pipelines live or die on attention performance. When ONNX Runtime and TensorRT can’t load the fused kernels they expect—because CUDA, cuDNN, or TensorRT versions don’t match—they quietly route to generic implementations. The model “works,” utilization hovers around 30–50%, and latency stretches beyond budget. The bill looks the same; the work is slower.Upon closer examination, the artifacts are precise. Provider load logs declare success with a tell: “Falling back to default kernels” or “xFormers disabled.” You’ll see TensorRT plan deserialization fail with “incompatible engine; rebuilding,” which triggers an on‑node compile. Engines built on one minor version of TensorRT won’t deserialize on another. The rebuild completes, but the resulting plan may omit fused attention or FP16 optimizations. The race finishes—without spikes, tensor core duty cycles stay muted.Here’s the counterintuitive part. Teams interpret “it runs” as “it’s optimal.” In this environment, nothing is accidental—if Scaled Dot Product Attention isn’t active, if xFormers is off, if cuDNN reports limited workspace, performance collapses politely. The simple versi

    22 мин.
  6. Stop Fixing Legacy Java: The AI That Does It For You

    -2 ДН.

    Stop Fixing Legacy Java: The AI That Does It For You

    Stop Fixing Legacy Java—Let the AI Do ItStill hand-upgrading legacy Java? That’s not craftsmanship; that’s unpaid penance. Manual modernization is a failure mode—slow, error-prone, and permanently behind. The truth? AI agents now handle the drudgery with receipts.Here’s what you actually get: time back, CVEs gone, and cloud bills that stop bleeding. We’ll walk a narrative case study—stack, benchmarks, results—plus a full audit trail so governance can breathe. There’s one metric that embarrassed finance and delighted security—stay for that. Now, here’s what happens when you let Copilot App Modernization drive.Case Setup: The Legacy Stack and the Modernization MandateBaseline first. We’re dealing with a Java 8-era Spring application—classic MVC plus a sprinkle of scheduled jobs—built with Maven, running on AWS. Conservative governance, noisy alerts, everyone swears the app is “stable” while PagerDuty begs to differ. The stack has drift: parent POMs forked years ago, dependency versions pinned like insect specimens, and a CI pipeline that only passes if you chant. Average user behavior? Ignore the red badges, silence the scanner, and pray the next sprint includes “tech debt.” Spoiler: it never does.Pain inventory. Version drift means modern libraries won’t resolve without exclusions. Dependency hell: transitive roulette where one logging upgrade detonates your HTTP client. Unpatched CVEs sit there, politely waiting for an exploit kit. Idle compute waste? Autoscaling that never scales down, instances at 8% CPU while finance funds a space heater. Add brittle configs: environment variables baked into user data, stateful file writes on disk, and secrets living where secrets shouldn’t live.Constraint: this is audio-only. No performative heroics, no live tab-switching to Stack Overflow. We rely on reproducible artifacts—reports, commit diffs, scanner outputs. Because guesswork is not a strategy, and “worked on my laptop” isn’t evidence.Why Java 21. Virtual threads change concurrency from a scarce resource to a commodity. Thousands of lightweight threads with minimal overhead; throughput goes up, tail latency comes down. Garbage collection improvements—G1 and ZGC refinements—reduce pause times. The Foreign Function and Memory API is stable, which matters if you’re calling native code or wrestling with off-heap buffers. Net effect: measurable performance and maintainability gains. Most people think upgrading is cosmetic. Incorrect. You get cheaper concurrency and fewer stalls—directly visible in service-level graphs.Migration scope: AWS out, Azure in. Align with enterprise standards, consolidate billing, and plug into the platform your identity, policy, and observability already inhabit. We’ll target Azure App Service or Azure Spring Apps depending on the workload profile—simple app, App Service is fine; Spring-heavy microservices with scaling nuance, consider Azure Spring Apps. For data, the mandate is Azure SQL Database; yes, you can keep PostgreSQL on Azure, but the business wants consolidation, so we’ll map the path and show the trade-offs.Governance stance: every action lands in Git. Diffable, reversible, attributable. The agent generates a plan, opens issues, and proposes commits. You approve. It resolves builds, patches dependencies, applies code transformations using known recipes, regenerates the SBOM, and reruns scanners. If something doesn’t pass, it loops—no alt-tab pilgrimage. And when it can’t proceed, it asks for input and documents why. See the difference? Work becomes auditable instead of anecdotal.Before you let an agent touch anything, you assess. Automated inventory across modules, dependencies, build plugins, and runtime configs. Risk-ranked findings with references to advisories and documentation. Cloud readiness flags for service bindings, environment variables, and stateful traps that break when containers come and go. Cost baselines: compute hours, idle percentages, and the egress patterns that finance pretends not to notice until month-end.You might be thinking, “We can triage that by hand.” Fascinating. And you’re still surprised the app crashes. The average user misses the long-tail issues—deprecated APIs deep in the scheduler, a logging bridge masking duplicate class conflicts, or that one library pin that blocks everything from moving. The agent doesn’t miss them because it doesn’t get bored.So the modernization mandate is simple and final: upgrade to Java 21, eliminate CVEs, containerize, migrate to Azure, wire CI/CD with controlled rollouts, enforce policy via approvals and Key Vault, and cut cost without cutting reliability. All changes trace back to commits with rationale. No black box. No swaggering hero-commits at 2 a.m.Assessment first—because guesswork is not a strategy. Then we execute.Assessment: The AI Exposes Technical Debt with ReceiptsHere’s what actually happens when you press assess. The agent doesn’t “scan.” It inventories—code, build files, plugins, transitive dependencies, Docker bits, environment variables, startup scripts, even those stray shell wrappers someone copy-pasted in 2017. It builds a dependency graph, annotates it with CVE data, and ranks risk. Not vibes—severity, exploitability, reachability. It’s the Windows Registry of your app’s reality. Not just a list—your structural spine, exposed.The truth? Most people think they know their stack. They don’t. The agent finds the forked parent POM with a logging version pin that blocks every downstream patch. It flags duplicated SLF4J bridges that shadow each other like feuding roommates. It catches the servlet container that’s quietly three releases behind because your CI only tests the happy path. And yes, it maps deprecated APIs you’ve been calling for years because nobody wanted to touch the job scheduler. Spoiler alert: you’re touching it now.CVEs next. Severity breakdown, affected libraries, and references to advisories—direct links, not rumors. Critical and high get top billing, but it also identifies whether the vulnerable code paths are reachable by your application. Reachability matters. If a transitive library has an issue but your code never calls the vulnerable class, it’s still flagged, but the agent prioritizes fixes that reduce real risk first. You get the remediation options: bump versions, add exclusions, or swap artifacts entirely. That’s a menu, not a mystery.Upgrade readiness comes with receipts. Java 21 requires you to stop pretending it’s 2009. The agent runs OpenRewrite recipes against your codebase in dry-run mode, showing exactly which APIs are deprecated, which imports must change, and where behavior shifts lurk. It calls out illegal reflective access, j.u.c. quirks, and the tiny landmines waiting in XML configuration. It notes frameworks that are ready—Spring versions, plugin compatibility—and those that need coercion. No hand-waving. Every proposed change links back to docs and migration notes.Cloud readiness is where your infrastructure sins go to be cataloged. The agent identifies stateful traps: writing temp files to local disk during requests, caching sessions in memory across instances, storing secrets in a text file under /opt because someone “needed it to work.” It flags environment variable usage that assumes EC2 metadata patterns. It points out service bindings for Redis, queues, and databases that won’t survive container churn. Then it proposes bindings the Azure way: connection strings moved to configuration, Key Vault for secrets, managed identities for auth. You know, like adults.Now the finance shocker: cost baselines. The agent pulls compute hours, instance sizes, scale patterns, and idle percentages from telemetry and infra definitions. It estimates egress costs based on outbound patterns—yes, that one noisy batch job that hurls data across regions every night gets a line item. It translates all of this into a monthly number that doesn’t care about your anecdotes. This is the number that embarrassed finance and delighted security. Why? Because eliminating CVEs while cutting spend is the only religion both teams share.Artifacts or it didn’t happen. The agent produces a plan file with sections: CVE remediation steps, Java upgrade recipes, build changes, code transformations, containerization moves, and cloud target mappings. It opens issues per workstream, tags owners if you want, and scaffolds commits in a separate branch—clean, small diffs with rationales in the messages. SBOM generated, signed, and versioned. Vulnerability scanner outputs attached. That’s audit-ready from step zero.You want traceability? Every finding links to an advisory or a source document: NVD entries, project release notes, OpenRewrite recipe documentation, Azure migration guides. When it suggests replacing a library, it cites compatibility matrices. When it recommends moving a secret, it points to platform guidance on Key Vault and managed identities. It’s not just “because AI said so.” It’s “because this standard, right here, says so.”Controls remain human. The plan sits in Git, awaiting approval. You can adjust priorities, reject a remediation strategy, or demand a different target service—Azure App Service versus Azure Spring Apps—with the trade-offs listed plainly. The agent adapts, reruns the assessment delta, and updates artifacts. No sulking.Once you see the receipts, the posture changes. You stop debating if modernization is “worth it” and start sequencing the work. And yes, the average user will still try to ship a feature first. Fascinating. Meanwhile, the agent has already mapped the shortest path to a secure, compliant, cheaper runtime. Approve the plan. Then watch it do the work you keep postponing.Automated Upgrade: From Java 8 to Java 21 Without the DramaPlan approved, so the agent stops talking and starts doing. The loop is simpl

    21 мин.
  7. The Secret Architecture That Makes AI Agents Actually Work

    -3 ДН.

    The Secret Architecture That Makes AI Agents Actually Work

    Most people think AI agents fail because of weak prompts. Not true. Prompts guide reasoning—but executors, validation, and workflow graphs are what guarantee reliability. In this episode, we reveal the architecture behind stable, predictable, enterprise-ready AI agents using Microsoft 365 Graph, Azure OpenAI, and Copilot Studio. You’ll learn why traditional prompt-only agents hallucinate tools, break policies, and silently fail—and how a contract-first, validator-enforced architecture fixes accuracy, latency, cost, and auditability. This is the mental model and blueprint every AI builder should have started with. What You’ll Learn 1. Why Prompts Fail at Real-World Operations The difference between cognition (LLMs) and operations (executors)Why models hallucinate tools and ignore preconditionsHow executors enforce idempotency, postconditions, and error recoveryThe “silent partial” problem that breaks enterprise workflows2. Workflow Graphs: The Map AI Agents Actually Need Nodes, edges, state, and explicit control flowWhy DAGs (directed acyclic graphs) dominate reliable workflowsState isolation: persistent vs ephemeral vs derivedCompensations and rollback logic for real-world side effectsMemory boundaries to prevent cross-session leakage3. Secure-by-Design: Validation That Stops Chaos Static graph validation: cycles, unreachable nodes, contract checksRuntime policy checks: RBAC, ABAC, allowlists, token scopesInput/output sanitization to prevent prompt injectionSandboxing, segmentation, and safe egress controlsImmutable logging and node-level tracing for auditability4. Microsoft Integration: M365 Graph + Azure OpenAI + Copilot Studio Least-privilege Graph access with selective fields and delta queriesChunking, provenance, and citation enforcementAzure OpenAI as a reasoning layer with schema-bound outputsCopilot Studio for orchestration, human checkpoints, and approvalsReliable execution using idempotency keys, retries, and validation gates5. Before/After Metrics: The Proof Higher factual accuracy due to citation-verified groundingLower p95 latency via parallel nodes + early exitReduced token cost from selective context and structured plansDramatic drop in admin overhead through traceability and observabilityStable first-pass completion rates with fewer human rescues6. The One Gate That Prevents Dumb Agent Mistakes The pre-execution contract check:Capability matchPolicy compliancePostcondition feasibilityDeny-with-reason paths that provide safe alternativesPreventing privilege escalation, data leaks, and invalid actionsKey Takeaways Prompts are thoughts. Executors are actions. Validation is safety.Reliable AI agents require architecture—not vibes.Graph validation, policy enforcement, and idempotent execution turn “smart” into safe + correct.Grounding with Microsoft Graph and Azure OpenAI citations ensures accuracy you can audit.A single contract gate prevents 90% of catastrophic agent failures. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    27 мин.
  8. Stop Building Dumb Copilots: Why Context Engineering Is Your Only Fix

    -3 ДН.

    Stop Building Dumb Copilots: Why Context Engineering Is Your Only Fix

    In this episode, we break down the real reason most Copilots fail inside the Power Platform: context debt. Your model isn’t hallucinating because it’s dumb—it’s guessing because you starved it. We walk through a complete, repeatable context engineering blueprint for Copilot Studio and Power Automate, designed to eliminate hallucinations, reduce cross-tenant drift, and dramatically cut latency and cost. You’ll learn how to build the four-layer spine every enterprise Copilot needs: System Context, Retrieval, Tools, and Policies—plus the missing governance layer most teams overlook. What You’ll Learn 1. Why Your Copilot Fails (Context Debt) How missing system rules and vague identity cause inconsistent answersWhy ungrounded Dataverse data leads to hallucinated fieldsThe hidden impact of undefined tools and cross-environment driftHow governance gaps create policy violations and compliance risks2. Layer 1 — System Context That Doesn’t Drift The System Message pattern used in real enterprise deploymentsIdentity, scope, refusal policy, schema awareness, and logging rulesHow to parameterize system context across Dev/UAT/ProdThe “six-line” system message formula that stops ambiguity cold3. Layer 2 — Retrieval That Grounds to Dataverse How to build a Dataverse-first schema indexWhy PDFs and document libraries aren’t grounding—and how to fix themChunking, security trimming, hybrid search, and caching for speedThe schema grounding checklist every agent needs4. Layer 3 — Tooling + Policy Enforcement Turning Power Automate flows into safe, least-privilege “agent verbs”How to encode preconditions, sensitivity flags, and refusal logicUsing DLP, Conditional Access, Purview, and MIP labels to prevent driftWhy you need an admin kill-switch (and how to add one)5. End-to-End Build (With Before/After Metrics) Step-by-step Copilot Studio + Power Automate buildSchema indexing, tool catalog, prompt wrappers, and environment bindingsBefore/after metrics: latency, token usage, hallucinations, policy adherenceReal example: correcting an invalid “fast-track to approved” requestKey Takeaways Models don’t provide truth—they only predict text. You provide the truth.The four layers—System, Retrieval, Tools, Policies—eliminate drift and hallucination.Dataverse schema is the spine; documents are secondary.Governance isn’t optional: DLP, Conditional Access, and sensitivity labels define reality.A fully engineered context cuts latency, costs, hallucinations, and audit risk. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support. Follow us on: LInkedIn Substack

    24 мин.
См. все (373)

Об этом подкасте

Welcome to the M365 Show — your essential podcast for everything Microsoft 365, Azure, and beyond. Join us as we explore the latest developments across Power BI, Power Platform, Microsoft Teams, Viva, Fabric, Purview, Security, and the entire Microsoft ecosystem. Each episode delivers expert insights, real-world use cases, best practices, and interviews with industry leaders to help you stay ahead in the fast-moving world of cloud, collaboration, and data innovation. Whether you're an IT professional, business leader, developer, or data enthusiast, the M365 Show brings the knowledge, trends, and strategies you need to thrive in the modern digital workplace. Tune in, level up, and make the most of everything Microsoft has to offer. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support.

Информация

  • Автор
    Mirko Peters
  • Годы выхода
    2 тыс.
  • Выпуски
    373
  • Ограничения
    Без ненормативной лексики
  • Авторские права
    © Copyright Mirko Peters / m365.Show
  • Сайт подкаста
    M365 Show Podcast

Вам может также понравиться