Exercise 3: Copilot Boundary Enforcement (~15 min)

Goal: Prove to decision-makers that Copilot’s agentic capabilities operate under more governance than a human developer — with branch restrictions, automated security checks, full audit trails, and admin-controlled policies.

📝 Open docs/copilot-governance-checklist.md — verify each governance layer as you work through the scenarios below.

This exercise is structured around 5 questions that skeptical decision-makers ask about AI in the development workflow.

Scenario 1: “Can the AI go rogue?” — Branch & Merge Restrictions

Step 1. Open the trust-boundary-demo repository and start the Copilot coding agent with a task:

@copilot Create a function in app.py that reads database configuration 
from environment variables and returns a connection string.

Step 2. Observe how the agent operates within governance:

• ✅ Creates a copilot/ prefixed branch (e.g., copilot/add-db-config) — agent can only push to copilot/ branches
• ✅ Commits code changes to that branch — never directly to main or master
• ✅ Opens a pull request for review — merge requires human approval
• ✅ Cannot merge its own PR — existing branch protection rules apply

Key proof: The AI cannot bypass your existing governance. It operates 
WITHIN the same branch protections as every human developer.

Scenario 2: “Does the AI check its own work?” — Built-in Security Validations

Step 3. Examine the PR that the coding agent just opened:

1. Navigate to the Checks tab on the PR
2. Look for CodeQL analysis — the agent’s code is automatically scanned for security vulnerabilities
3. If any new dependencies were introduced, dependency review checks them against the GitHub Advisory Database
4. Secret scanning verifies no credentials or API keys are embedded in the generated code
5. The agent performs a self-review before opening the PR — it iterates on issues it finds in its own code

Key proof: The AI applies the SAME security checks that protect human 
code — CodeQL, dependency review, secret scanning — AUTOMATICALLY, 
every time. A human can forget to run checks. The agent cannot.

[!NOTE] These built-in validations require no additional configuration — they are enabled by default for all Copilot coding agent users when GHAS is active.

Scenario 3: “Can I see everything it did?” — Audit Trail

Step 4. Navigate to the Organization audit log and trace the agent’s actions:

1. Go to Organization settings → Audit log
2. Filter for recent Copilot agent activity
3. Observe the complete trace:

# Query audit log for Copilot agent activity
gh api /orgs/YOUR_ORG/audit-log?phrase=action:copilot --paginate | head -20

Key proof: Every AI action is fully auditable. For regulated 
industries, this means Copilot produces a MORE complete audit 
trail than most human developer workflows.

Scenario 4: “Can I control where and how it operates?” — Governance Controls

Step 5. Examine the admin policy controls:

1. Navigate to Organization settings → Copilot → Policies:
   • ✅ Coding agent can be enabled or disabled at enterprise, organization, and repository levels
   • ✅ Specific repos can be excluded from agent access
   • ✅ Model selection can be restricted by enterprise policy
   • ✅ Third-party agent access can be controlled
2. Review .github/copilot-instructions.md (included in this repository) — these custom instructions act as organizational guardrails for the agent:

## Security Requirements
- **Never** suggest hardcoded credentials, API keys, or secrets
- **Always** use parameterized queries for database access
- **Always** validate and sanitize user input
- **Always** use environment variables for configuration

Step 6. Test that the agent follows custom instructions:

@copilot Write a function that queries the user table in a PostgreSQL 
database and returns all users matching a given email address.

Observe the generated code follows the instructions:

• ✅ Uses parameterized queries (e.g., cursor.execute("SELECT * FROM users WHERE email = %s", (email,)))
• ✅ Does not hardcode credentials
• ✅ Uses environment variables for database connection
• ✅ Includes input validation

Key proof: You control the AI's behavior through policies 
(enterprise/org/repo) AND through custom instructions (per-repo). 
You have a kill switch at every level.

Scenario 5: “What about unauthorized repositories?” — Trust Boundary

Step 7. Verify the agent respects the trust boundary:

1. Enabled org repo — Copilot coding agent runs ✅ (just demonstrated)
2. Disabled org repo — Navigate to a repo where admin has NOT enabled coding agent → agent is not available ❌
3. EMU personal repository — Copilot features are NOT available:

EMU users can only use Copilot (chat, completions, coding agent) in 
organization-owned repositories where Copilot licenses have been 
assigned by an admin. This is a fundamental trust boundary constraint.

Key proof: The AI only operates where you EXPLICITLY allow it.
No access creep. No unauthorized repos. No shadow AI.

Expected Outcome

• Copilot coding agent operates under 5 layers of governance: branch restrictions, automated security checks, full audit trail, admin policy controls, and trust boundary enforcement
• Decision-makers can verify: the AI agent is MORE governed than a typical human developer
• Custom instructions guide suggestions toward secure patterns
• Every action is auditable for compliance

[!TIP] Run scripts/verify-exercise3.sh to validate your Exercise 3 completion.

Key Insight

“Copilot coding agent is not an uncontrolled assistant. It operates under MORE automated governance than a human developer — branch restrictions, CodeQL analysis, dependency checks, secret scanning, audit logging, and admin-controlled policies. A human can forget to run security checks. The agent runs them automatically, every time.”

🔗 Hand-off to Workshop 2

We’ve established WHERE development happens and WHO has access. But what happens when someone — human or AI — tries to push insecure code into this trusted space?

That’s what guardrails are for.

In Workshop 2 — 🔒 Secure by Design Guardrails, we enable full GHAS (CodeQL, dependency review, push protection) and configure required status checks on the branch protections we created here. The trust boundary becomes an enforced security perimeter.