GitHub Copilot Security & Enterprise Guide

GitHub Copilot Security & Enterprise GuideSecurity, Code Review & Enterprise1Intermediate → Advanced/github-copilot/security-enterprise/

Every cluster before this one made Copilot more capable. This one is about the cost of that capability, and who carries it.

The framing that causes the most damage is the one that treats this as a security-versus-productivity trade. Organisations that lock everything down get developers using personal accounts on personal machines, which is worse than what they were afraid of. Organisations that enable everything discover their policy surface only when something goes wrong. Neither is governance.

Key takeaways

• Governance is a set of controls, not a switch. Identity, policy, models, agents, data, tools, review, audit and metrics are separate decisions.
• Policy precedence is not uniformly restrictive. Within one enterprise the least restrictive setting usually wins across organisations. Across enterprises, the most restrictive almost always does.
• Controls are per-surface. The Copilot app and Copilot CLI are governed by separate, independent client policies.
• Every control has a documented edge. Content exclusion does not cover Edit and Agent modes; public-code blocking is not a licence determination.
• Human accountability does not transfer. A review Copilot performed is not an approval anyone can point to afterwards.

Two failure modes, both common

Before the controls, the two ways organisations get this wrong — because the remedy for each looks like the cause of the other.

Lock everything down. Public-code matching blocked, agents disabled, MCP off, CLI unavailable, models narrowed to one. It feels defensible and it produces shadow adoption: developers with a personal subscription, on a personal machine, pasting work code into a chat window that carries none of the enterprise commitments. The organisation now has all of the exposure and none of the audit trail. The control was real; the outcome was worse than doing nothing.

Enable everything. Every feature on, every agent permitted, MCP unrestricted, because the tooling is impressive and nobody wants to be the person who slowed it down. This works fine until an agent with a broad token does something outward facing, at which point the organisation discovers it has no policy, no audit answer and no idea who decided.

The failure is the same in both cases: a single decision standing in for a set of decisions. What follows is that set.

The stack of controls

Copilot governance is often discussed as though there were one setting. There are 13 distinct controls in this cluster’s data alone, and they sit at different layers with different owners.

1. 1IdentityWho has a seat, and under whose agreement.
2. 2PolicyWhich features, clients and agents are permitted.
3. 3Model accessWhich models may serve requests.
4. 4Agent accessWhich agents may act, and where.
5. 5Data accessWhat Copilot may read — content exclusion lives here.
6. 6Tools and MCPWhat it can reach outside the repository.
7. 7Code reviewWhat examines the output before it lands.
8. 8AuditWhat was changed, by whom, and when.
9. 9MetricsWhether any of it is being used.
10. 10Human governanceHuman judgementWho decides, and who is accountable.

Steps marked Human judgement are the ones that do not get delegated — they are where you decide whether what Copilot produced is actually right.

Each layer fails differently. A permissive identity layer means people you did not intend have access. A permissive tools layer means an agent can reach production. A missing audit layer means you cannot answer what happened. Teams that think of governance as one decision usually configure exactly one layer.

The trust boundary

Where the boundary sits determines what the controls can even do.

1. 1DeveloperHuman judgementChooses what to ask and what is open.
2. 2Prompt and contextThe request, plus whatever context the client attached.
3. 3Copilot serviceGitHub's infrastructure.
4. 4Model providerProcessing happens on the provider's infrastructure.
5. 5ResponseA suggestion. Nothing has happened to your code yet.
6. 6ValidationCompile, test, lint, scan.
7. 7Human approvalHuman judgementThe point at which it becomes yours.

Steps marked Human judgement are the ones that do not get delegated — they are where you decide whether what Copilot produced is actually right.

For agents the boundary extends past the response, and that is the whole difference:

1. 1AgentDecides which tool to call.
2. 2ToolsWhat it was permitted to invoke.
3. 3External systemsIssue trackers, cloud APIs, monitoring, deployments.
4. 4Side effectsSome of which nothing can undo.

A suggestion you reject costs nothing. A tool call that posted a comment, triggered a deployment or rotated a credential has already happened by the time you evaluate it. That asymmetry is why tool access gets stricter governance than model access, and why Cluster 7 spends so long on tool lists.

Where requests are processed

Any honest answer about private repositories starts here, because the protection is contractual rather than physical.

So requests do leave GitHub’s own systems for several model families. What protects them is a set of commitments, not a network boundary. The private repositories lesson works through what that means for a security review, and what it does not license you to claim.

The controls, and what each one misses

• Content exclusion

  Scope

  Repository, organization and enterprise rules over file paths

  Requires

  Copilot Business or Copilot Enterprise

  Applies to

  Inline suggestions and Chat in supported IDEs; excluded files are not reviewed in Copilot code review

  What it does not cover

  Does not apply to Edit and Agent modes in Copilot Chat, symlinks, or repositories on remote filesystems. Copilot may still use semantic information an IDE supplies indirectly, such as type information, hover definitions and build configuration.

• Suggestions matching public code

  Scope

  Enterprise and organization policy over completion suggestions

  Requires

  Copilot Business and Copilot Enterprise; blocked by default for Business

  Applies to

  Code completion suggestions

  What it does not cover

  Filters suggestions that match indexed public code. GitHub reports such matches in under one percent of suggestions, and the index refreshes every few months, so recently published code may not be matched. It is not a licence-compliance determination.

• Code referencing

  Scope

  Attribution shown alongside matching suggestions

  Requires

  Available where public-code matching is allowed

  Applies to

  Supported IDEs

  What it does not cover

  Shows URLs of files containing matching code and the licence name where one was found. Absence of a reference is not evidence that no match exists.

• Secret scanning and push protection

  Scope

  Repository and organization

  Requires

  GitHub feature, independent of the Copilot plan

  Applies to

  Pushes and repository contents

  What it does not cover

  Detects supported provider patterns. A credential in a shape it does not recognise — an internal token format, a database connection string, a private key pasted into a comment — can still land. It also does not see what you typed into a prompt.

• MCP allowlist in managed-settings.json

  Scope

  Enterprise, distributed via a .github-private repository or MDM

  Requires

  Enterprise-managed clients

  Applies to

  Copilot clients that read enterprise managed settings

  What it does not cover

  A deny rule from any source blocks a server, and a server must match an allowlist entry at every layer. Built-in defaults are always allowed. Unresolved variables cause a server to be blocked.

• MCP private registry

  Scope

  Enterprise or organization, with Allow all or Registry only

  Requires

  Public preview

  Applies to

  Copilot CLI and IDEs

  What it does not cover

  Does not apply to cloud agents running on GitHub. GitHub documents managed settings as the more secure, generally available method.

• Copilot audit log events

  Scope

  Enterprise and organization audit log

  Requires

  Copilot Business or Copilot Enterprise

  Applies to

  Plan, policy, seat and agent activity events

  What it does not cover

  Records administrative changes and documented agent events, retained for 180 days. It is not a transcript of developer prompts or Chat conversations in an IDE.

• No training on Business and Enterprise data

  Scope

  Contractual and platform commitment

  Requires

  Copilot Business and Copilot Enterprise

  Applies to

  Copilot requests made under those plans

  What it does not cover

  Prompts are still processed by model providers on their infrastructure. GitHub documents zero-retention arrangements with providers for generally available features, with limited exceptions noted for beta and preview features.

Every control here has a documented edge. The limitation line is the part worth designing around.

Two of those deserve emphasis in the pillar because they are the ones most often misdescribed.

Reading a control honestly

A habit worth forming before the detailed lessons, because it applies to every control GitHub ships and every one it ships next.

Vendor documentation describes what a control does. It rarely leads with what the control does not reach, even when that is documented — the exceptions live further down the page, in a limitations section, phrased neutrally. A security model built from the headline and not the exceptions will be wrong in exactly the places that matter.

Three questions turn a control description into something you can design with.

Which surfaces does this cover? Not “does Copilot support this” but “on which of the surfaces my developers actually use”. Content exclusion is the worked example: entirely real, and absent from Agent mode.

What is the failure mode when it does not apply? Does the control fail closed (the feature is unavailable) or open (the feature works, unrestricted)? Content exclusion in an unsupported mode fails open — the file is simply readable. That is a very different risk from a feature that refuses to run.

What would I be claiming if I relied on this? Write the sentence out. “Our proprietary algorithms cannot reach a model provider because those paths are excluded” is a claim that the documentation does not support. “Inline suggestions and Chat in supported IDEs will not use those files” is a claim it does.

Policy precedence

This is the single most surprising thing in the cluster, and getting it backwards produces a policy that does nothing.

Read the first row twice. Where several organisations inside one enterprise have configured the same policy differently, GitHub documents that the least restrictive setting usually applies, with exceptions. Administrators almost universally assume the opposite — that the tightest setting anywhere wins — and build a governance model on that assumption.

The practical consequence: if a policy matters, set it at the enterprise level. Setting it in one organisation and assuming it constrains a user who also belongs to a more permissive organisation is how a control silently stops applying.

Who can change what

The delegated permission is worth knowing about. “Manage enterprise AI controls” exists as a custom role permission precisely so that policy management does not require handing out full enterprise ownership — which is otherwise what happens, and is a much larger grant than anyone intended.

The policy surface

Copilot policies by scope, status and surface

Policy	Enterprise	Organization	Status	Surfaces it governs
Suggestions matching public codePublic Code	Yes	Yes	GA	Code completion suggestions
Content exclusionContent Exclusion	Yes	Yes	GA	Inline suggestions and Copilot Chat in supported IDEs, and Copilot code review
Copilot cloud agent policyAgents	Yes	Yes	GA	Copilot cloud agent
Third-party agent controlsAgents	Yes	Not documented	Status not documented	Partner and third-party agents that work alongside the cloud agent
MCP servers in CopilotMCP	Yes	Yes	GA	Copilot clients that support MCP
MCP allowlist in managed-settings.jsonMCP	Yes	No	GA	Copilot clients that read enterprise managed settings
MCP private registryMCP	Yes	Yes	Public preview	Copilot CLI and IDEs
Copilot CLI client policyCLI	Yes	Yes	GA	Copilot CLI only
Copilot in GitHub.comPrivacy	Yes	Yes	GA	GitHub.com web surfaces
Model access policiesModels	Yes	Yes	GA	Surfaces that offer model selection
Copilot code review effortCode Review	Not documented	Yes	GA	Copilot code review on pull requests
Automatically request Copilot code reviewCode Review	Not documented	Yes	GA	Pull requests in targeted repositories and branches
Copilot metrics accessUsage Metrics	Yes	Yes	GA	Usage, Impact and Code Generation dashboards, and the metrics REST API

What administrators most often get wrong

• Suggestions matching public code. Blocking filters suggestions; it is not a licence-compliance guarantee. GitHub's public-code index refreshes every few months, so very recently published code may not be matched.
• Content exclusion. GitHub documents that exclusion does not apply to Edit and Agent modes in Copilot Chat, to symlinks, or to repositories on remote filesystems. It is not a general data boundary.
• Copilot cloud agent policy. Disabling or restricting the cloud agent does not automatically disable third-party agents. Those are governed separately.
• Third-party agent controls. Each third-party agent requires its own configuration. There is no single switch that covers every agent.
• MCP allowlist in managed-settings.json. This is the generally available mechanism GitHub recommends. The MCP private registry is a separate public preview feature and GitHub does not present it as the more secure option.
• MCP private registry. GitHub states private registries apply to Copilot CLI and IDEs but not to cloud agents running on GitHub.
• Copilot CLI client policy. The GitHub Copilot app and Copilot CLI are governed by separate, independent client policies. Allowing one does not allow the other.
• Model access policies. Restricting a model does not restrict the surfaces that never offered model choice in the first place.
• Copilot code review effort. Balanced consumes more AI credits and may use marginally more GitHub Actions minutes. A repository can override the organization default.
• Automatically request Copilot code review. This is a branch ruleset rule, not a Copilot settings toggle, so it is targeted by branch and repository patterns like any other ruleset.
• Copilot metrics access. The usage dashboard metrics exclude Copilot CLI usage, so CLI adoption does not appear there.

Three things in that table cause more incidents than the rest combined.

The CLI is a separate client policy. GitHub states the Copilot app and Copilot CLI are governed by separate, independent client policies, so you can allow one without allowing the other. An organisation that believes it has disabled Copilot in the terminal by disabling something else has not.

Restricting the cloud agent does not restrict third-party agents. They are governed independently and each requires its own configuration.

MCP registry scope is narrower than it sounds. Private registries apply to Copilot CLI and IDEs, not to cloud agents running on GitHub — and GitHub documents the registry as a public preview while presenting managed settings as the generally available, more secure method.

Governance works through the full decision set; MCP security covers the allowlist mechanics.

Enablement is a security control

This is the part that gets left out of security-led rollouts, and it belongs in the pillar rather than in an appendix.

A developer who understands what Copilot is doing makes better decisions than a developer working under a policy they do not understand. That is not a morale argument, it is a threat-model argument: the person at the keyboard is the last control in every diagram on this page, and the quality of that control depends entirely on what they know.

Concretely, four things change behaviour more than any policy toggle.

Knowing what the tool is weak at. A developer who knows generated authorisation logic is frequently subtly wrong reads it differently. One who believes the tool is generally reliable does not.

Knowing where the boundary is. Someone who understands that content exclusion does not cover Agent mode will not casually open an excluded file in an agent session. Someone who believes exclusion is absolute will.

Knowing what the prompt does. The single highest-value habit — not pasting credentials — is a knowledge problem, not a policy problem. No setting prevents it.

Knowing who to ask. Most policy questions have an answer; what is usually missing is a named person. An organisation where “can I use this MCP server” routes somewhere gets better outcomes than one where it does not.

Review is where the risk is caught

Copilot code review is the control most teams reach for first, and it is genuinely useful — provided nobody believes it is exhaustive.

1. 1ChangeHuman judgementWritten by a person, an agent, or both.
2. 2TestsDeterministic, and yours.
3. 3Static analysisLinting and type checking.
4. 4Security scanningCode scanning, secret scanning, dependency review.
5. 5Copilot reviewReads the diff and comments.
6. 6Human reviewHuman judgementJudgement about whether it should exist at all.
7. 7MergeHuman judgementUnder whatever protection the branch has.

Steps marked Human judgement are the ones that do not get delegated — they are where you decide whether what Copilot produced is actually right.

GitHub states plainly that Copilot is not guaranteed to spot all problems in a pull request. It also excludes dependency management files, log files and SVG files from review, and does not review files that content exclusion covers.

The order matters as much as the presence. Copilot review sits after your deterministic checks, not instead of them — a linter that catches something every time is worth more than a reviewer that catches it usually. Code review covers the capability in full and automatic review covers turning it on without generating noise nobody reads.

Who owns which layer

Governance stalls more often on unclear ownership than on missing features. The layers in the diagram above have natural owners, and naming them prevents the common outcome where everyone assumes someone else configured something.

Enterprise owners and AI managers own the policies that must hold everywhere: which clients are permitted, which agents may run, whether MCP is available at all, and the managed settings that clients cannot override. This layer is small and should change rarely.

Organization owners own seats, the policies the enterprise delegated, content exclusion for their repositories, code review defaults, and — importantly — telling developers what changed. Most of the day-to-day surface lives here.

Repository administrators own the rulesets that decide where automatic review runs, repository-level content exclusion, and the instruction files that shape what a review looks for.

Security engineering owns the determination of which paths need exclusion, which MCP servers are acceptable, what the high-risk code categories are for this codebase, and the incident path when something goes wrong.

Engineering leadership owns the questions no configuration answers: whether adoption is working, what to do about a team that has stopped reviewing carefully, and whether the trade the organisation made is the one it wanted.

Secrets

The rule that prevents most of the damage is short enough to memorise.

Agents widen this further: they read files, run commands, and see terminal output. The secrets lesson covers the full surface, including how agent and Actions secrets differ.

Prompt injection, at organisation scale

Cluster 7 covers the mechanism. What changes at enterprise scale is who can reach the input.

The premise is simple: Copilot reads text, and text can contain instructions. In a private repository worked on by twelve colleagues, the set of people who can write text an agent will read is twelve people you employ. In a public repository accepting issues, it is everyone. In an organisation with MCP servers connected to a ticketing system, it includes every customer who can file a ticket.

That last case is the one worth planning for, because it does not feel like a security boundary when you configure it. A support-ticket MCP server is obviously useful. It is also a channel through which people outside your organisation supply text to a system holding your credentials.

The organisational version of this is a rule about combinations rather than individual features: no single configuration is dangerous, but “reads customer-supplied text” plus “holds a write-capable token” is, and it is a combination two different people can create without either noticing.

Code that deserves a second look

Not all generated code carries the same risk. These are the categories where a plausible-looking answer is most expensive:

The common thread is that failure is silent. A wrong sort order shows up in testing; a wrong authorisation check does not show up until someone exploits it. Security best practices turns this into a working practice.

Compliance, carefully

Enterprise conversations about Copilot reach compliance quickly, and this is where technical writing most often overreaches.

Using Copilot does not make an organisation compliant with anything. There is no configuration of the controls on this page that produces SOC 2, ISO 27001, GDPR or HIPAA compliance as an output. What the controls do is give an organisation things it can point to when its own compliance process asks how AI-assisted development is governed.

The honest division of labour looks like this.

GitHub supplies contractual terms, privacy documentation, a subprocessor list, the technical controls in this cluster, and audit events. Those are inputs.

Your organisation supplies the determination — which regulations apply, which data classifications exist, whether the controls satisfy them, what residual risk is accepted and by whom. That determination is a legal and security judgement about your circumstances, and nothing on this site can make it.

The practical version for an engineering leader: collect the control configuration, the audit evidence and the vendor documentation, and hand that to the people whose job the determination is. Do not try to make the determination in an architecture document.

What does not transfer

One principle underlies every lesson that follows, and it is easy to lose in the detail of policy names.

Automation can be delegated. Accountability cannot.

Copilot can review a pull request, and the review may be good. It is still not an approval — nobody can point to it afterwards and say a person judged this change acceptable. An agent can open a pull request; the decision to merge remains a human act with a human’s name on it. Content exclusion can keep a directory out of inline suggestions; the decision about what belongs in that directory is somebody’s job.

This is not a caution against using any of it. It is the reason the last step in every diagram on this page is a person, and the reason a governance model that removes that step has not simplified anything — it has only made it harder to say who decided.

Measurement

Adoption metrics are where governance meets reality, and where the most confident wrong conclusions get drawn.

GitHub publishes usage, impact and code-generation dashboards, and a metrics REST API at enterprise and organisation scope. What you cannot do is take any single number as proof of value. If teams using Copilot merge faster, that is a correlation involving people who chose to adopt a tool — which is not the same population as people who did not.

Team adoption covers what the dashboards actually contain and how to combine them with the qualitative signal they cannot capture.

A starting configuration

Concretely, for an organisation adopting Copilot without an existing governance model. This is a defensible default, not a recommendation to stop thinking.

Identity. Seats assigned deliberately rather than to everyone, under Business or Enterprise so the contractual commitments and the policy surface exist at all.

Public code. Leave matching blocked. It is the Business default, it costs almost nothing, and it removes one category of argument later.

Content exclusion. Configure it for the paths where it genuinely matters — generated credentials directories, vendored third-party code, anything under a contractual restriction — and write down, in the same place, that it does not cover Agent mode. The note is as important as the rule.

Agents. Start with the cloud agent enabled for selected organisations rather than the whole enterprise. It is one of the documented policy states and it is what a pilot looks like. Configure third-party agents separately and explicitly, because nothing else will.

MCP. Enable the policy, then define an allowlist in managed settings before anyone needs one. An allowlist written under time pressure after a server is already in use is a worse allowlist.

Code review. Turn on automatic review through a ruleset targeting the default branch of one repository. Leave “review new pushes” off initially. Expand when the team says the comments are useful, not before.

Audit and metrics. Confirm someone can actually retrieve both. The moment to discover that nobody has the permission is not during an incident.

Ownership. Name the person who owns this configuration. Not a team — a person, with a named deputy.

What this cluster assumes

You have used Copilot enough to have opinions about it, and you are now responsible for something beyond your own use of it — a repository other people contribute to, a team’s practice, an organisation’s configuration, or the question of whether any of this is safe to expand.

It assumes you can read a policy description sceptically, which the earlier section is meant to help with. It does not assume you administer a GitHub enterprise, hold a security qualification, or have any existing governance model to extend.

Where a lesson describes an administrative surface you cannot reach, the useful reading is still the shape of the control and its limits — that is what tells you what to ask the person who can reach it.

Vocabulary

Three terms get used loosely in this area, and the looseness causes real confusion.

Policy here means a setting an administrator configures — which features, clients or agents are available. It is enforcement.

Governance means the set of decisions an organisation has made about those policies, plus the things no policy covers. It includes permissive decisions.

Control means a mechanism that constrains what can happen — content exclusion, an MCP allowlist, branch protection. Every control in this cluster has a documented edge, and the edge is the part worth knowing.

A fourth distinction matters more than it sounds. Enforced means a configuration makes something impossible. Documented means it is written down and people are expected to follow it. Both are legitimate; conflating them is not, because a documented rule described as enforced will eventually be tested by somebody who assumed it would stop them.

Reading this cluster

Twelve lessons is a lot to work through in order, and most people should not.

If you are deciding whether Copilot is acceptable at all, read private repositories and secrets. Between them they cover what a security review actually asks.

If you have just been made responsible for a configuration, start with organization management, then governance for the decision framework.

If you are a developer wanting to work safely, read security best practices and secrets. The rest is administration.

If you are turning on code review, the two review lessons and nothing else.

If agents or MCP are already in use, read MCP security before anything else here — it is the area where a configuration nobody assessed is most likely to already exist.

Common questions

Does Copilot train on our code? GitHub states plainly that it does not use Copilot Business or Copilot Enterprise customer data to train AI models, and documents zero-retention arrangements with model providers for generally available features. That commitment is plan-dependent, which is one of the substantive reasons organisations move off individual plans.

Can we stop Copilot reading a particular directory entirely? Content exclusion covers inline suggestions and Chat in supported IDEs, and keeps those files out of Copilot code review. It does not cover Edit and Agent modes. “Entirely” is therefore the wrong word on at least one surface your developers already use, which is why the limitation belongs in the same sentence as the feature.

Who can see what developers asked Copilot? Audit logs record administrative changes and documented agent events, retained for 180 days — not IDE prompts and not Chat conversations. If your governance model assumes prompt-level visibility, it assumes something that does not exist.

Is one policy enough? No, and this is the most expensive assumption on the list. The Copilot app and Copilot CLI alone are governed by separate, independent client policies; agents are separate again; and third-party agents are separate from the cloud agent. Each one is a decision somebody has to make explicitly.

Do we need Enterprise, or is Business enough? Business carries the policy surface, content exclusion and the training commitment that most organisations are actually asking about. Enterprise adds the enterprise-wide controls, delegated administration and the broader audit picture. Business and Enterprise cover each in operational terms rather than as a feature list.

Where should we start? The starting configuration above, then governance once you know which decisions your organisation actually needs to make.

A worked scenario

The abstractions above, applied to one organisation, because governance decisions are easier to judge against a concrete situation.

A payments company. Around two hundred engineers across six teams, one GitHub enterprise with four organisations, a compliance obligation that is real, and a codebase where authorisation bugs are the expensive category.

Identity. Copilot Enterprise, managed seats, assigned on request. Personal subscriptions actively hunted and replaced, because the contractual position is the entire reason for the plan.

Policy floor. Set at the enterprise: client policies for the app and CLI decided explicitly, MCP enabled with a managed-settings allowlist, cloud agent enabled for two organisations by custom property. Everything else delegated.

Content exclusion. Three paths, not thirty — the vendored payment-processor SDK, a directory of test fixtures containing realistic card data, and one customer-supplied module under a contractual restriction. Each with a written reason. The Agent-mode limitation recorded in the same document.

Code review. Automatic review on default branches across all repositories at Lite, new pushes off. The two services handling card data run Balanced. Every repository has an instructions file naming the authorisation patterns that have caused incidents.

Human review. Branch protection requires human approval on the authorisation library and the payment services regardless of what Copilot said.

MCP. Two servers approved — GitHub’s own read-only, and an internal monitoring server with a read-only credential. The ticketing server was requested and declined, because it returns customer-supplied text and the requesting team also had the operations server.

Metrics. Collected quarterly, reported with the CLI exclusion stated, and explicitly not used in performance conversations.

Where to go next

Eleven lessons, grouped by the question they answer.

Reviewing what Copilot produces — code review for the capability, automatic review for the automation, and security best practices for the developer’s own habits.

Understanding what Copilot can see — private repositories, secrets, and MCP security for everything outside the repository.

Running it for other people — Copilot Business, Copilot Enterprise, organization management, and governance.

Making it stick — team adoption, which is Academy Lesson 100 and closes the curriculum.

Next

Copilot code review starts with the control most teams turn on first — and the one whose limitations matter most, because a review people over-trust changes their behaviour for the worse.